OwS Core Cncepts: Directives vs. Statements
The OwS interpreter passes multiple times through a MS Word document:
- The OwS tokenizer analyzes the document, detects the parts that must be processed by OwS and splits these parts of the document into a set of OwS commands and parameters. During this pass all OwS directives within the document are executed.
- The OwS object manager parses through the token sequence and builds up the defined hierarchy of OwS objects. It registers all object names within their definition scopes so that concept relationships defined at the beginning of a document may even refer to concepts that are defined at the end of the document. During this pass the syntax of all OwS statements is checked. Errors and warnings are written to an error log.
- The OwS parser analyzes all OwS statements, sets object properties, resolves object references and loads missing information from the terminology server. The result of this processing step is a set of code system definitions based on the OwS internal information model.
- The OwS FHIR converter takes this representations of the defined code systems and transforms them into an information model that complies to the FHIR ValueSet resource definition (and the defined CTS2-LE extensions to this definition).
- The OwS XML Writer takes the FHIR ValueSet resources and writes these to the filesystem as XML files (that comply to the FHIR XML binding).
The OwS language provides 2 kinds of commands:
- OwS Directives are interpreted by the tokenizer. Most directives are linked with style sheets and direct the tokenizer how to process a paragraph of text that is formatted with this style sheet. It is important to notice that directives only manipulate the text of the document; directives do not "know" anything about OwS objects. All OwS Directives start with a hash-sign (#).
- OwS Statements are interpreted by the parser. Statements define and manipulate OwS objects and are used to set up the defined code systems. Some Directives (e.g. #heading) are used to define objects, too.
Generally spoken, OwS Statements provide all the OwS functionality but look ugly within a document. The only use for OwS Directives is to hide away the OwS statements by manipulating the text in a way that these statements can be generated out of style sheets and text templates. Therefore, all the OwS tokenizer does on OwS Directives is to internally manipulate the document in a way that OwS statements are properly inserted into the text in order to form a valid OwS program.
E.g. the Directive
#heading 1 codesystem .Name ( .URI )
does not much more than to translate each level-1 headmine within a word document into an OwS define statement . E.g. the following MS Word headline text
| Style Sheet | Text | Comment | ||||
|---|---|---|---|---|---|---|
| Überschrift 1 |
|
The style sheet "Überschrift 1" matches the #heading directive. Therefore the headline text is split into its building blocks and transformed into an object definition statement. |
would be translated into this sequence of OwS Statements:
define codesystem(Body Parts) {
set (Body Parts).URI = (http://sample.com/bodyparts)
}