DSSSL - Document Style Semantics And Specification Language             
ISO/IEC 10179:1996

 

DSSSL Construction Rules 

By Didier PH Martin, July 08, 1999

Contents

* Home Page
* Introduction 
* The Structure of a Construction Rule 
* The Root Construction Rule
* The Element Construction Rule
* The Default Construction Rule
* The Query Construction Rule
* The ID Construction Rule
* The Construction rule Event Firing Mechanism

Introduction

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
  • The action part also called the construct expression

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:

  • The root construction rule (supported by OpenJade)
  • The element construction rule (supported by OpenJade)
  • The Default construction rule (supported by OpenJade)
  • The Query construction rule (not supported by OpenJade)
  • The id construction rule (supported by OpenJade)

Extract from the DSSSL specifications (ISO/IEC 10179:1996 section 12.4.1)

"The construction-rules in a style-specification (see 7.1) specify how a node in the
source grove is to be processed. Each construction-rule matches some (possibly empty) set of the nodes in a source grove..... A construction-rule includes a construct-expression, which is an expression returning an object of type sosofo. A sosofo is a specification of a sequence of flow objects to be added to the flow object tree."

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.

  • query
  • id
  • element
  • default
  • root

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. 

The Structure of a Construction rule

In DSSSL, all rules are structured as in the example below:

(Construction-rule-name (pattern-matching-expression)
   (action-construct-expression )
)
rule associated to the document:
(root
   (make display-group
       (process-children)
   )
)
rule associated to all elements contained in the source document:
(default
      (process-children)
)

Note: Some construction rules like: root and  default do not have a pattern part. This is because these rules are respectively matched to the source document and all the document's elements. The root construction rule is fired only once for the source document. The default construction rule is fired for each document's elements.

rule associated to document's element class :
(element (section header)
   (make paragraph
        font-family-name: "Helvetica"
        font-weight: 'bold
        font-posture: 'oblique
       (process-children)
   )
)
rule associated to a particular element uniquely identified with an id:
(id ("ref34")
   (make paragraph
        font-family-name: "Helvetica"
        font-weight: 'bold
        font-posture: 'oblique
       (process-children)
   )
)
rule associated to a query:
(query q-class 'pi )
   (make paragraph
       literal "Processing instruction:"
       (node-property 'system-data (current-node))
   )
)

figure 1

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.

<?xml version="1.0" ?>
<book>
   <section>Construction rules
       <header> Introduction</header>
   </section>
   <section>Construction languages
       <header>Introduction</header>
   </section>
</book>
the rule below is fired when the heading element is encountered:
(element (section header)
   (make paragraph
        font-family-name: "Helvetica"
        font-weight: 'bold
        font-posture: 'oblique
        (process-children)
   )
)

figure 2

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

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

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

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

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.

XML document:
<?xml version="1.0" ?>
<book>
   <section>Construction rules
       <header> Introduction</header>
   </section>
   <section>Construction languages
       <header id="ref32">Introduction</header>
   </section>
</book>
DSSSL rule:
(query q-class 'pi )
   (make-paragraph
       literal "Processing instruction: "
       (node-property 'system-data (current-node))
   )
)
Output:
Processing instruction: xml

Not supported by OpenJade

The id Construction Rule

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.

XML document:
<?xml version="1.0" ?>
<book>
   <section>Construction rules
       <header> Introduction</header>
   </section>
   <section>Construction languages
       <header id="ref32">Introduction</header>
   </section>
</book>
DSSSL rule:
(id ("ref32")
   (make paragraph)
)
Output:
Introduction

Supported by OpenJade

The Construction Rule Event Firing Mechanism

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:

  • A node for the element usually identified in the document by a tag. For instance in a XML document, an element is composed of a start and end tag with in between the data.
  • A node for the element's data. In the original document, this is what is enclosed by the tags.

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:

Introduction

Figure 5 - data displayed from the flow object properties

 


All trademarks herein are the property of their respective owners. 
Copyright   1999-2003 Didier PH Martin, All rights reserved. Created by Didier PH Martin, modified: April 7, 2003