[This local archive copy mirrored from the canonical site: http://www.arbortext.com/xslwp.html 980127; links may not have complete integrity, so use the canonical document at this URL if possible.]
by Paul Grosso
1997 August 29
Placing XSL into perspective
Where XSL fits into the XML specification effort
The XML language—a subset of the full SGML language defined by the ISO 8879 standard—is designed to be easier to described, process, and use. The overall XML process includes:
XSL—the eXtensible Style Language—is the name being given to the language designed, as part of the overall XML effort, to be used to specify a stylesheet for an XML document.
Where XSL fits into SGML and related technology
One of the raisons d'être of XML is to standardize a subset of the ISO standards that enable the markup of structured information. The full standards include:
The XML language was scoped as a subset of SGML; XLL—or eXtensible Linking Language—is basically a subset of HyTime; and XSL is expected to be a subset of DSSSL. However, the syntax of DSSSL as defined in the 1996 version of the standard—based on the Scheme programming language—was seen as suboptimal for average use. XSL is currently being conceived as a mapping of a subset of DSSSL into what is mostly a declarative (rather than programming) language. Existing declarative stylesheet language such as the FOSIs developed as part of the CALS initiative has influenced the design of XSL.
The point of XSL
XSL is a stylesheet language designed to satisfy the widest possible cross section of the Web community.
Web authors are seen as creating content at three different levels of sophistication:
XSL is intended to be accessible to the "markup" level user by providing a declarative solution to most data description and rendering requirements. Less common tasks are accommodated through a graceful escape to a familiar scripting environment. This approach is familiar to the Web publishing community as it is modeled after the HTML/JavaScript environment.
Capabilities provided by XSL allow:
Relationship of XSL to DSSSL
The charter for the XML activity specifies the use of DSSSL for the stylesheet language component. XSL is based on DSSSL and is compatible with the fundamental design principles and processing model of this standard. However, the development of XSL has identified usability issues with the current DSSSL standard which has led XSL to diverge in various ways.
Therefore, in parallel with the development of the XSL specification, a proposal for an amendment to DSSSL will be developed so that with the amendment it would be a superset of XSL. The amended standard would be compatible with current DSSSL but would have three kinds of additions:
XSL incorporates the subset of DSSSL flow object classes and characteristics that was specified in DSSSL-O, the subset of DSSSL suggested for the specification of stylesheets for on-line presentation.
Relationship of XSL to HTML and CSS
XSL as currently proposed supports all of the functionality of the World Wide Web Consortium's Cascading Style sheet language (W3C's CSS) so that an accurate mechanical translation from CSS to XSL is possible. For the purposes of the current XSL proposal, CSS is defined by the W3C recommendation "Cascading stylesheets, level 1" and W3C working drafts "CSS Printing Extensions" and "Positioning HTML with Cascading Stylesheets."
A simplified overview of XSL
XSL enables formatting
information to be associated with elements in the source
document thereby allowing the production of formatted
output. In the XSL/DSSSL model, the formatted output is
created by first producing a tree of flow objects based
on the document instance and style specification, and
then allowing the formatter to process this tree. Each
flow object has a class which represents a kind of
formatting task. Examples of flow objects include paragraph, character , horizontal-rule, etc. A flow object also has a
set of named characteristics (properties), which further
specify the formatting.
The association of elements in the source tree to flow objects is specified through construction rules. A construction rule contains (1) a pattern that identifies the set of elements in the source tree for which this rule is relevant, and (2) an action that specifies a resulting sub-tree of flow objects to construct in response to each source document element for which this rule is relevant.
The pattern part of a construction rule must contain a target-element element which indicates the source document element to which the rule applies. In addition to the element type name itself, the pattern also allows identifying applicable elements by their context within the source, including consideration of:
Element ancestry can be represented within the pattern by mirroring the hierarchy found in the source document. The element element has identical attributes to the target-element, but implies that the source element named by its type attribute is part of the context of the applicable element in the source rather than the element to which this rule will be applied. The containment hierarchy of the element elements in the pattern indicate their contextual relationship to the target-element element in the source.
For example, the
following pattern matches title source elements that have a section element as a parent and a chapter element as a grandparent:
<element type="chapter"
<element type="section"
<target-element type="title"/
</element
</element
Ancestry or descendancy beyond an unbroken sequence of immediate parents or immediate children can also be specified as part of the context for determining whether a rule applies to a given source element. Wildcards can be specified within the pattern using the any element or using an occurrence of the element element with no explicit "type".
Attributes on the source element or any of its ancestor or descendant elements can also be used to determine whether a particular construction rule applies. The attribute element is included in an element or target-element element to test the value of a source attribute.
The following example
matches an item element that has for its parent a list element whose liststyle attribute has the value enum:
<element type="list" <attribute name="liststyle" value="enum"/ <target-element type="item"/ </element
Other details of the source document structure can be tested with XSL. The range of patterns expressible in XSL is a superset of what can be specified by FOSIs.
Once the rule that is to be applied to the source element has been identified, the action part of the rule is invoked. The structure of the elements comprising the action represents the structure of flow objects to create. Flow object elements may be combined with literal text and programmatically generated text to create a flow object sub-tree. For example, the following rule causes a chapter title element in the source to produce the objects in the flow object tree necessary for the desired formatting of the title, that is, a sequence consisting of a paragraph (in a 14-point font) containing the contents (children) of the title followed by a horizontal rule:
<rule
<!-- pattern --
<element type="chapter"
<target-element type="title"/
</element
<!-- action --
<sequence
<paragraph space-before="6pt" font-size="14pt"
<children/
</paragraph
<horizontal-rule/
</sequence
</rule
The ECMAScript standard provides the basis for the XSL scripting language. ECMAScript is the standardized specification of JavaScript. Within an action, an ECMAScript expression may be used to compute generated text. The value returned by the expression is converted to a string and then to a sequence of character flow objects. This mechanism of "escaping" beyond the basically declarative nature of XSL allows for complete extensibility of the language.
What is expected to happen with XSL?
The initial XSL draft proposal was developed by representatives of ArborText, INSO, and Microsoft as well as several other key members of the DSSSL standard working group. Several key W3C personnel have endorsed the principle of the proposal. The proposal was co-submitted to the W3C on August 25-27 by ArborText, INSO, and Microsoft who are all W3C members
The proposal is expected to be discussed and finalized by the W3C XML working group. The timeframe is not set, but discussion may commence soon, and in any case a final draft of XSL is scheduled to be ready by the end of November.
Given the attention and expertise put into this draft and the relatively wide range of input it has already had, it is reasonable to expect that the final draft form of XSL will not be substantially different from the current proposal. XSL functionality should be powerful enough to handle what can be done in FOSIs, and it should be feasible to map FOSIs into XSL. At the same time, XSL's declarative form should enable the development of user-friendly interfaces to creating and modifying XSL stylesheets.
ArborText is committed to supporting the easy use of XSL for specifying the presentation of documents marked in XML and SGML as well as providing a migration path from FOSIs to XSL stylesheets. It is reasonable to hope that the development and deployment of XSL will finally provide a widely accepted way to specify presentation style for XML and SGML documents thereby enabling XML/SGML to be much more effective as an interoperable format for the markup of structured information.