DSSSL Construction RulesBy Didier PH Martin, July 08, 1999
DSSSL provides several construction rules associated to different document's objects. Before any DSSSL processing occurs on a SGML or XML document, the document is parsed and transformed into a tree like structure (i.e. a grove), each document's element becomes a node of this tree. Construction rules are applied on these nodes. A rule is composed of two parts:
The pattern matching part of a construction rule is used to make an association between a particular node (i.e. grove element) and the rule itself. The action part specify what is done when the rule match a tree's node. A construction rule is fired when a tree's node match its rule pattern.
Actually, DSSSL support five (5) kind of construction rules:
Extract from the DSSSL specifications (ISO/IEC 10179:1996 section 12.4.1)
Some construction rules are more specific than others. The list below shows each construction rule sorted by its level of specificity. The most specific being at the beginning of the list.
This specificity is a kind of rule conflict resolution. For instance, if a grove element is pattern matched to an "element" rule, then the "default" rule is not fired.
Construction rules are contained in the style-specification-body element.
In DSSSL, all rules are structured as in the example below:
The pattern part of a rule is necessary to indicate which element or which document fragment is associated to this rule. Or more specifically to with grove's node the rule is associated to. For instance, in the example above, the rule is fired when the heading element is encountered in the processed document. The heading element is contained by the section element as show below.
Each time a pattern is encountered, the rule is fired. In the example above (figure 2) the rule with the element construction rule having a pattern set to "section header" is fired twice.
The root construction rule is associated to the SGML or XML document. It is not associated to any document's element. Thus, this rule is always fired if it is present in a DSSSL script.
When a SGML or XML document is parsed, it is transformed into a tree (i.e. a grove) the tree's root it the document node. This is why the root construction rule is associated to the document.
Supported by OpenJade
The element construction rule is associated to any document's element that match the element rule's pattern. For instance, in the previous example (figure 2), each time the "header" element contained in a "section" element is encountered the rule is fired. However, is a "header" element would be contained in an other element than the "section" element, the rule would not be fired. So, only element construction rules having a pattern matching a corresponding element or element's hierarchy are fired.
Supported by OpenJade
The Default construction rule is associated to all elements but not to the document itself. So, it is associated to all document's elements and not to the document. Thus, this event is fired for all the source document's elements.
Note: If a document's node has been matched to a construction rule like, for instance, a "element" construction rule, then the "default" rule is not fired. The "default" rule will be fired for any node that is not matched to a particular rule.
Supported by OpenJade
The query construction rule process what is returned from a query expression. A query expression returns a node list. The rule is processed against this node list.
For instance, if we want all processing instructions "system data" to be included in the output document then we would use the query construction rule as in the example below.
Not supported by OpenJade
The id construction rule is used to process a specific element in the source document. Contrary to the element construction rule which is fired for any element instance, this rule is fired only for a specific element identified with an id. Thus, in the example below, only the element with the id="ref32" is associated to the rule.
Supported by OpenJade
To better understand the event firing mechanism, we have to understand first how the original document is transformed by one the fundamental DSSSL component: the grove engine. Before the original document is processed by a DSSSL engine, it is first transformed into a tree also called a grove. All document's components are transformed into a grove node. Thus, for each document's element is created two nodes:
The grove above is incomplete and do not contains all the nodes that may have been created by parsing the document, but this simplified view illustrates how the document and its elements are transformed into nodes.
You probably noticed that the root construction rule in the figure 1 contained, in the action part of the rule, a (process-children) construct. This construct tells the DSSSL processor to process all the root node's descendents. Thus, in the example, to process the "book" element and all its contained nodes. In figure 2, the element construction rule having a pattern "(section header)" also contains the same (process-children) construct. In this context, it indicates to the DSSSL engine to process all "header" descendent nodes, which correspond to the element's data "Introduction" (luckily for both element instances).
The (process-children) construct tells the DSSSL engine to process all descendent nodes. Descendent nodes could be, for instance, an element node, or, an element's data node. If the element has properties, then all the properties are contained in the element's node as sub nodes. For example, if the section element would have a "type" property, then we would find a "type" node as child of the section node. However, the (process-children) construct is applied only to elements and data nodes, not on property nodes. In the figure 3, the nodes are in a certain order. This is on purpose. When the DSSSL engine encounters the (process-children) construct it first processes the data node located at the beginning of the nodes collection. To process a data node simply means to create a flow object containing the element's data and all the properties created by the action part of the rule. Then, (process-children) continue in the element's node collection and when a child element is encountered, the rule with the corresponding pattern is fired.
Question: In the element construction rule having the "section header" pattern, which grove node or nodes is or are processed.
Response: The element's data. The paragraph flow object properties are applied to the element's data. Because this element has no children elements, only the element's data is processed. Thus, the element's data for both "header" element instances is "Introduction". A flow object containing the data is created with properties like: font-family-name="helvetica", font-weight="bold", font-posture="oblique". Thus, the element's data will be displayed as below:
All trademarks herein are the property
of their respective owners.