[See note on the origin of this provisional draft. Back to XSL Page.]

+ Hewlett Packard 1997. All Rights Reserved.

A comparison of Spice and XSL

Summary

CSS has proven to be highly effective and easy to learn for simple applications. Both Spice and XSL are designed to meet the needs of more complex applications for richer style sheets that offer capabilities such as:

Both Spice and XSL are proposals for extensible style sheet languages for rendering XML:

In the Web community, many more people know CSS than know DSSSL. Spice allows people to reuse CSS style rules directly. With XSL, you have to learn an entirely new syntax. The history of computing shows that leveraging what people are already familiar with wins over attempts to get them to do something new.

Spice is an extension of ECMAScript to support CSS style rules along with some improvements for representing symbolic values and prototypes. XSL is an application of XML with the ability to embed scripting functions written in ECMAScript.

Spice leverages W3C's work on CSS and DOM. CSS provides the syntax for style rules as well as the properties for standard flow objects, while DOM provides the basis for accessing and manipulating the document parse tree.

Selectors

Its true that CSS is weaker than XSL in this respect, but proposals for richer selectors are being discussed and we can expect CSS selectors to continue to increase in power in successive releases. The proposals cover the same features as XSL:

  1. element ancestry;
  2. element descendants;
  3. wildcards in the ancestry/descendant hierarchy (arbitrary ancestors/descendants);
  4. attributes on an element;
  5. position of an element relative to its siblings;
  6. uniqueness of an element relative to its siblings.

The following table summarizes ideas for selector syntax for Spice style rules:

H3, H4 an H3 or an H4 (CSS1)
LI P a P which is a descendant of an LI (CSS1)
LI >> P a P which is a direct child of an LI (CSS2)
H1+P a P that immediately follows an H1 (CSS2)
(H1 IMG)+P a P element that immediately follows an H1 element with an IMG as a descendant (Spice?)
(H1 IMG!)+P an IMG which is a descendant of an H1 and which is immediately followed by a P (Spice?)
DIV P:firstChild a P that is the first element in a DIV (CSS2)

Discussions with HTML tool vendors suggest that providing too powerful a selector syntax is likely to slow down rendering, impacting the ability for a smooth refresh when the document is dynamically changed under script control. This doesn't effect printing, where more powerful selectors would be beneficial.

DSSSL has a very weak selector mechanism for selecting which rule to apply to a given element. This is made up for by the ability for flow objects to walk the document parse tree and control subsequent processing based upon the results.

Spice follows DSSSL in this, and gives you the full power of the W3C Document Object Model for doing so. The above selector syntax applies only to the style rules and doesn't constrain the ability to do much richer things with flow objects.

Example of XSL style rule for an element called orders

    <rule>
        <target-element type="orders"/>

        <P font-size="14pt" font-family="serif">
            <children/>
        </P>
    </rule>

the same rule in CSS:

    orders
    {
        font-size: 14pt;
        font-family: serif;
        display: block
    }

and in Spice:

    style orders
    {
        fontSize: 14pt;
        fontFamily: serif;
        display: block
    }

Spice doesn't permit the use of '-' in property names to avoid confusion with the infix operator for minus.

Here is an XSL rule that matches the emph and the strong elements:

    <rule>
        <target-element type="emph"/>
        <target-element type="strong"/>
        <SPAN font-weight="bold">
            <children/>
        </SPAN>
    </rule>

In Spice this looks like:

    style emph, strong
    {
        fontWeight: bold;
        display: inline
    }

XSL uses two kinds of rules:

  1. Style rules with <style-rule> which can be used for cascading property definitions.
  2. Construction rules with <rule> that are required to specify which flow objects are constructed for each element. The flow objects are named after HTML elements.

Spice, by contrast:

  1. Uses CSS style rules for cascading property definitions; however, unlike XSL, these can directly indicate which flow objects are to be constructed for each element, via the display property. The standard flow objects have the same names as used by CSS, e.g., block, inline and none.
  2. Supports flow objects written in Spice, Java or ActiveX which specify the details of how an element is laid out, including the creation of subsidiary flow objects and out of order processing. Simple Spice style sheets just use style rules, importing the standard flow objects.

Flow Objects

These are used to render the document structure.

XSL allows you to define macros for aggregate flow objects and refer to the composite as if it were a single flow object. This example matches an element <warning> and inserts the text string "Warning!" at the start of the contents:

    <define-macro name="warning-para">
      <box>
        <paragraph>
          Warning!
          <contents/>
        </paragraph>
      </box>
    </define-macro>

    <rule>
      <target-element type="warning"/>
      <warning-para font-size="14pt">
        <children/>
      </warning-para>
    </rule>

Spice allows you to define flow objects with the full power of a scripting language:

    prototype WarningPara extends block
    {
        function layout(element)
        {
            this.style.borderStyle = solid;
            this.append(new Text("Warning!"));
            ProcessChildren(element, this);
        }
    }

    style warning
    {
        fontSize: 14pt;
        display: WarningPara
    }

Layout methods can use a variety of functions to access the document using the full power of the W3C Document Object Model. This allows you to tailor the formatting according to the context.

XSL does allow you to include functions defined in ECMAScript, but only for use in the evaluation of properties.

Spice and XSL both allow you to use function calls in style rules. Spice further allows you to use flow objects defined in other languages such as Java and ActiveX. Spice further encourages interoperability by decoupling the names of flow object libraries from their implementations. According to the XSL submission, XSL will eventually provide a mechanism to allow the specification of new flow object classes and characteristics for the new classes.

Out of Sequence Processing

Normally, flow objects are generated in the same sequence as the elements in the document. On occasion, there is the need to process something out of sequence.

An example is the aural rendering of table cells. HTML 4.0 provides the means to associate each cell with one or more header cells. In the simplest case, you render the pertinent headers before the contents of each data cell.

The first step is to use the headers attribute on the data cell to get the list of ID values for each of the headers. The next is to iterate through the list, getting each header in turn and processing it in the context of the current flow. Finally, the content of the current element is processed:

    var hdrefs = GetAttribute(element, "headers");

    for (hdref in hdrefs)
    {
        header = GetElementByID(element, hdref);
        ProcessChildren(header, this);      
    }
 
    ProcessChildren(element, this);

A more sophisticated approach is to process the headers in a different mode. Modes are explained in the next section.

Note: both Spice and XSL provide a way to say which attribute name is used for SGML ID values.

Modes

Both Spice and XSL support a mechanism for rendering elements in more than one place, for instance to construct a table of contents based upon the headings that occur in the document.

The following shows how to alter the font size for an h2 element when formatting it in the toc mode. First, here is how you would write this in XSL:

    <rule>
      <target-element type="h2"/>
      <DIV font-size="14pt" font-weight="bold">
        <children/>
      </DIV>
    </rule>

    <rule mode="toc">
      <target-element type="h2"/>
      <DIV font-size="12pt">
         <children/>
      </DIV>
    </rule>

in Spice this becomes:

    style h2
    {
        fontSize: 14pt;
        fontWeight: bold;
        display: block
    }

    mode toc
    {
        style h2
        {
            fontSize: 12pt;
            display: block
        }
    }

To construct the table of contents you need to invoke the mode. In XSL you do this by setting the mode via an attribute of the <children/> element:

    <children mode="toc"/>

This is placed in the action part of an XSL rule, e.g.

    <rule>
      <target-element name="body"/>
      <DIV font-size="14pt" font-weight="bold">
        <children mode="toc"/>
      </DIV>
      <children/>
    </rule>

This rule processes the children of body elements twice: once to build the table of contents using the mode toc and once more to build the regular view of the document.

In Spice, you can set the mode directly in a flow object's layout method. You do this via the with mode statement:

    with mode toc
        ProcessChildren(element, flow);

Alternatively, you can use the with mode directive in a style rule to create a flow object and process it in a given mode, e.g.

    style #toc
    {
        display: block with mode toc
    }

You can specify that an element is to be processed in several modes as follows:

    style body
    {
        display: block with mode toc, block with mode regular
    }

The default mode is named regular.


Editor: Robert Stevahn, 11 December 1997.

+ Hewlett Packard 1997. All Rights Reserved.

[Provisional copy of the document from the editor:
From: "Robert Stevahn" <rstevahn@boi.hp.com>
Organization: Hewlett Packard Co.
To: Robin Cover <robin@acadcomp.sil.org>
Date: Tue, 24 Feb 1998 09:03:38 -0700
Mime-Version: 1.0
Content-Type: Multipart/Mixed; boundary=Message-Boundary-1467
Subject: Re: comparison of Spice and XSL
Reply-To: rstevahn@boi.hp.com
Cc: robin@acadcomp.sil.org]