This work was carried out at the Human Communication Research Centre, whose baseline funding comes from the UK Economic and Social Research Council, with support from both Microsoft and Sun.
XML as chartered included three components:
The document A Proposal for XSL grew out of discussions between James Clark, Istvan Cseri and Henry Thompson, and eventually involved significant representation from people intimately involved with both DSSSL and CSS.
The document submitted to W3C is expected to be the starting point for the XSL standardisation effort, which is in the process of being spun off from the XML effort within W3C.
As a W3C Note it has no official status beyond being on record as such.
Accordingly although this talk is about the document, not the thing itself, the document represents a pretty good guess as to what the thing itself will eventually look like.
XSL is notated with XML element types
DSSSL semantics without DSSSL syntax
A declarative approach, using XML to specify both the "pattern" and the "action" of construction rules.
An XML DTD for a set of flow object types and attributes adequate to provide on-screen display as well as some printing support.
Extensibility for both the declarative and procedural aspects.
Both the pattern and the action use XML nesting to represent source (respectively output) nesting.
The pattern is built up from element types
The action is uses element types named after flow-object classes (DSSSL or HTML, see below).
The example above translates into DSSSL as follows
A series of draft extensions to DSSSL exists, known as DSSSL2, which make translation from XSL to DSSSL easier.
component of element construction rules is much richer, extending what
is already possible with
match-element?, enabling the
richer XSL patterns to be translated.
Limited side-effects have been introduced to the expression language, to facilitate XSScript translation.
We could try translate our example into CSS as follows:
But that would of course be wrong:
titlecan't occur inside
font-weightproperty doesn't make sense on
Also the interpretation of nesting is different: The XSL pattern
title elements with
parent, where the CSS pattern matches
title elements with
ancestor at any remove.
XSL allows a rich declarative pattern language.
anyelement type allows arbitrary element structure to intervene.
typeattribute can be omitted
This will match
title elements under
only if the are not immediate children thereof.
There are other attributes on
allow specialisation to particular positions wrt siblings.
Attributes can be tested for
<attribute name="foo" value="bar"/>
<attribute name="foo" has-value="no">
Patterns can extend to children and descendants of the target element,
using the same element types (
attribute but not
This will match
employee elements provided they have at
This emphasises that in many cases the choice of attribute vs. sub-element in content models is pretty arbitrary.
id attributes provide privileged
syntax for CSS-style matching.
Style- rules without flow-object actions are additive.
With all these pattern variants, what happens if two rules match?
Drawing on both DSSSL and CSS, there are a set of precedence rules.
Basically, the richer the pattern, the higher precedence.
If all else fails, there are
A set of alternative, HTML4-based flow-objects are provided for.
Exactly how this will work is as yet unclear.
What about the need to actually compute things?
Still no round parens!
Can be used both in attributes and body
Two implementations known to be underway:
The HCRC Language Technology Group supplies a C-based XML parser and tool-kit.
We're giving a 4-day introductory document management course, covering document management both top down (was is document management and what can it do for you) and bottom-up (SGML, XML, DSSSL, XSL, HTML), with hands-on work, in the first week in December.
I'm doing a two-day electronic formatting course covering DSSSL, CSS and XSL for Technology Appraisals on 26 and 27 November.