Basic Events in the Omnimark Language

The following are some of the basic events Omnimark detects:

• document-start

• document-end

• element

• processing-instruction

document-start allows you to do processing and produce output before the beginning of an XML file, as shown in Listing 15.1.

Listing 15.1 A document-start Rule

1:  document-start  ;event
2:       output "&ltHTML>%n"     ;our action
3:       || "&ltHEAD>%n"
4:       || "&ltTITLE&gtOur first example</TITLE>%n"
5:       || "</HEAD>%n&ltBODY>"

The rule header on line 1 defines the event, which is document-start.

The rule body (lines 2-5) lists the actions to be executed. When the document starts (event), we write a string with HTML tags to the output (action).

%n stands for "end of line"
|| concatenates two strings
; starts a comment in your code

The result of this rule follows:

        &ltHTML>
        &ltHEAD>
        &ltTITLE&gtOur first example</TITLE>
        </HEAD>
        &ltBODY>

document-end allows you to do processing and produce output after the end of an XML file, as shown in Listing 15.2.

Listing 15.2 A document-end Rule

1:  document-end ;event
2:       output "</BODY>%n</HTML>%n"

When the document ends (event), we write a string with HTML tags to the output (action).

The result of this rule follows:

       </BODY>
       </HTML>

Line 3 being empty is the result of the %n end-of-line after the HTML end tag on line 2 of Listing 15.2.

When an element occurs you have to deal with three things:

• The start of the element

• Its content

• The end of the element

When dealing with the content of an element, parsing ceases in Omnimark to give you the ability to decide how and when to treat the content. You need explicitly get parsing going again. This can be done by using the following:

• The parse continuation operator %c as used in Listing 15.3.

• suppress, which continues parsing but suppresses the output of the parsed content as shown in Listing 15.4.

Listing 15.3 Using the Parse Continuation Operator

1:  element musician   ; event, when the element musician is encountered
2:       output "&ltHR>%n" ; at the start of the element
3:       output "%c"     ; continue parsing
4:       output "&ltHR>%n" ; at the end of the element

or:

Listing 15.4 Using the Suppress Action

1:  element meta   ; event, when the element meta is encountered
2:      suppress ; continue parsing but suppress output

Every rule must output the parsing continuation operator (%c) or suppress.

Make sure that every element rule contains %c or suppress.

Different actions may be needed depending on element attribute information. Refer to Listing 14.3, which shows an example of delivering different information depending on the experience of the user.

&ltsteps experience="firsttime"&gt...</steps>

versus

&ltsteps experience="donebefore"&gt...</steps>

Omnimark allows you to add conditions based on this attribute information to your rule headers, as shown in Listing 15.5.

Listing 15.5 Using a Condition Referring to an Attribute Value

1:  element steps when attribute experience = "firsttime"
2:       ;action

This rule is only triggered if we encounter, in the XML document, the element steps that has the attribute named experience set to a value of firsttime.

It is an error if more than one element rule applies to a single element in the document.

In the previous chapter we explained that event-driven systems keep some information about previously encountered nodes. This is also the case for Omnimark.

Omnimark gives access to:

• The parent element

• Ancestor elements

• Preparent elements

• Any open element

Or you can test for recently closed elements:

• The previous element

• The last subelement refers to the most recently closed subelement

Listings 15.6 through 15.9 show some examples of taking this context information into account.

Listing 15.6 Checking the Parent Element

1:       element li when parent is ol
2:       ;action

This rule is triggered if we encounter, in the XML document, an element li with, as parent, the element ol.

Listing 15.7 Checking the Ancestors

1:  element p when ancestor is li
2:       ; action

This rule is triggered if an element named p with an ancestor element named li is encountered in the XML document.

Listing 15.8 Checking the Previous Element

1:  element p when previous is title
2:      ; action

This rule is triggered if we encounter a p element after an element title in the XML document.

It is possible of course to combine these context checks, as shown in Listing 15.9.

Listing 15.9 Using a Combination of Context Conditions

1:  element def when parent of parent is ol
2:      ; action

This rule is triggered if we encounter a def element that has a grandfather named ol in the XML document.

You can also define and check context by counting elements:

• Using the occurrence-Returns the number of times the same element has been repeated, as used in Listing 15.10.

• Using the number of children-Counts the total number of children of the specified element seen so far, as shown in Listing 15.11.

Listing 15.10 Using an Occurrence Condition

1:  element li when occurrence = 2
2:      ;action

This rule is triggered if the element li is the second in a row of li elements.

Do	Don't

DO use "number of children" instead.

DON'T use occurrence to find the nth element in the parent element.

Listing 15.11 Using the Number of Children Condition

1:  element p when children of parent = 1
2:      ;action

This rule is triggered if the element p is the first child element of its parent.

Normally processing instructions are ignored unless you specify an event handler for processing instructions.

Example:

  processing-instruction "break"
       output "&ltBR>"

[Previous] [Contents] [Next]