| Experimental DSSSL extensionsContentsThis document descibes some
        experimental extensions to DSSSL that are implemented in OpenJade. 
	These are designed so that, with these extensions, DSSSL provides a 
        superset of the semantics XSL for flow
        object tree construction. OpenJade has a -2option that enables these extensions. These extensions do not include the
        additional flow object classes and characteristics that
        will be needed for XSL; in particular they do not include
        the HTML/CSS flow object classes.   Back to top
 The following features come from R4RS:
         
            assignment (set!)
                expressions (with restrictions)vectors (with restrictions) call-with-current-continuation(with restrictions)beginexpressionsmultiple expressions in
                procedure bodies, condclausesalternate in ifexpression optionalit is not an error when
                nothing matches in condorcaseexpressioneqv?andmemvprocedures; these behave as specified in R4RS for
                vectors but behave the same asequal?for strings and listsThis is so that case expressions can
                use eqv?as required by R4RS without
                breaking compatibility with existing DSSSL code
                which assumes case expressions with strings and
                lists will useequal?. R4RS
                specifies thateqv?should return #t
                when its arguments "should normally be
                regarded as the same object". R4RS treats
                strings and lists as mutable and its
                specification ofeqv?for strings
                and lists is consistent with this. So long as
                DSSSL keeps strings and lists as immutable data-types
                with value semantics, it is more consistent to
                defineeqv?to behave likeequal?for them. The use of side-effects is
        restricted. Assignment to top-level variables is not
        allowed. There is also the concept that a memory location
        can be read-only. When a memory location is read-only, it
        is an error to change that location. An memory location
        can be recursively marked as read-only; this means that
        the memory location along with all memory locations
        reachable from that memory location become read-only. A
        memory location is recursively marked as read-only when:  A continuation created with call-with-current-continuationcannot be called if it is read-only, and can only be used
        to return to a stack frame in the current call chain (sometimes
        referred to as upwards only). There's a voiddata
        type with a single value which can be written as#v.
        This is returned bycond,caseandifexpressions which don't match.  Back to top
 When a construction rule has a
        keyword argument list instead of a construct expression
        it is treated as a style rule. For example,  
(element H1
  font-size: 14pt
  font-weight: 'bold)
 The keyword argument list can
        include a use:keyword just as withstyleexpressions. See the XSL proposal
        for the semantics of style rules.  Back to top
 The syntax for element patterns is
        extended. These provide provide a superset of the
        semantics of XSL patterns. They are allowed both in
        element construction rules and in contexts where a match-element?pattern is currently allowed (egselect-elements,process-matching-children,process-first-descendant). A pattern is either a single gi or
        a list. A list consists of a sequence of gis, where each
        gi can be followed by one or more keyword/value pairs (where
        the value is always a single datum). A gi can be #t, a
        string or a symbol. The following keywords are allowed:  
            id:followed by a string or symbol
                class:followed by a string or symbol
                repeat:followed by one of the symbols
                *,+,?only:followed by one of the symbols
                of-type,of-anyposition:followed by one of the symbols
                first-of-type,first-of-any,last-of-type,last-of-anyattributes:followed by a list of name/value
                pairs; for backward compatibility with match-element?patterns in the current DSSSL standard theattributes:keyword can be omitted; #t and #f can be used as
                a value to test for presence or absence of
                attributes.children:followed by a pattern; each of
                the elements in the pattern must occur as child; repeat:is not allowed in children patterns; thechildren:qualifier is allowed on any gi in a pattern not
                just the last elementpriority:followed by an integer;
                multiple priority:qualifiers are
                allowed in a pattern and will be added togetherimportance:followed by an integer;
                multiple importance:qualifiers are
                allowed and will be added together Class attribute names are declared
        using  
(declare-class-attribute "class")
 or  
(declare-class-attribute class)
 Id attribute names can be declared
        similarily using declare-id-attribute. Some examples:  
(element (E importance: 42) ...)
(element (E attributes: (A1 V1)) ...)
(element (P E children: C) ...)
(element (P children: C priority: -11
          E children: C attributes: (A1 V1 A2 V2))
 ...)
(element (P E children: (A children: C B children: C)) ...)
The last is equivalent to the
        following in XSL syntax:  
<element type="P">
  <target-element type="E">
     <element type="A">
       <element type="C"/>
     </element>
     <element type="B">
       <element type="C"/>
     </element>
  </target-element>
</element>
 Back to top
 An or-elementconstruction rule has the syntax 
(or-element (pattern+) expression)
 where patternis any pattern that could be allowed in an element
        construction rule. It is equivalent to a sequence of
        element construction rules. For example,  
(or-element (H1 H2 H3)
  font-weight: 'bold)
(or-element ((H1 TITLE) (H2 TITLE) (H3 TITLE))
  font-weight: 'bold)
 is equivalent to  
(element H1
  font-weight: 'bold)
(element H2
  font-weight: 'bold)
(element H3
  font-weight: 'bold)
(element (H1 TITLE)
  font-weight: 'bold)
(element (H2 TITLE)
  font-weight: 'bold)
(element (H3 TITLE)
  font-weight: 'bold)
  Back to top
 A flow object macro can be defined
        like this:     
            
                | 
                    (declare-flow-object-macro
                        list-item ((indent 1in) (marker "\bullet")
                        #!contents contents)(make paragraph
 first-line-start-indent: (- indent)
 start-indent: (+ indent (inherited-start-indent))
 (make
                        line-field
 field-width: indent
 (literal marker)
      
                        )contents
  ))
 (root
 (make simple-page-sequence
 (make paragraph
 (literal "Para 1")
       
                        )(make list-item
 (literal "Item 1")
 (make list-item
 indent: .5in
 marker: "\black-circle"
 (literal "Sub item 1.1")
             
                        )       
                        )(make list-item
 font-weight: 'bold
 (literal "Item 2")
 (make list-item
 (literal "Sub item 2.1")
             
                        )        
                        )(make paragraph
 (literal "Para 2")
       
                        )    )) | If the formal argument list
        includes #!contentsthe flow object behaves
        like a compound flow object, otherwise like an atomic
        flow object. Inherited characteristics can be specified;
        these are applied to a sequence flow object which is
        automatically wrapped around what is returned by the body
        of the flow object macro. The preceding formal arguments
        are the non-inherited characteristics; like keyword
        arguments they can be specified either asid(in which case they default to #f), or as(id
        init-expression). Note that flow object macros are
        quite different from ordinary procedures in that the
        macro body is not evaluated when the make expression is
        evaluated, but rather when the flow object is to be added
        to the tree; this allows (inherited-c)and(actual-c)procedures to be used in flow object macro
        characteristics, non-inherited as well as inherited, just
        as with normal flow objects. It is also possible to use(inherited-c)and(actual-c)procedures in the body of the flow object macro; they
        will return the same result as if they were used in the
        specification of a characteristic on the invocation of
        the flow object macro. For an example of a library built
        with the macro facility read: Simple
        XML to HTML Conversion and Rendition Example   Back to top
 Most characteristic values can now
        be specified as strings and will be converted
        appropriately. For boolean valued characteristics any of
        the strings "true","false","yes"and"no"are acceptable.  Back to top
 The question mark that can be
        omitted from those DSSSL characteristic names that end
        with a question mark. This is because the question mark
        is not (and cannot reasonably be made) a legal XML name
        character.   Back to top
 |