Lists Home |
Date Index |
- From: Russell Chamberlain <firstname.lastname@example.org>
- To: email@example.com
- Date: Mon, 15 Sep 1997 09:29:37 -0400
I'm _extremely_ happy that someone (Microsoft) has put forward an
XML-formatting proposal (XSL - Extensible Style Language) to the W3C that:
1) Is represented in XML
This is _absolutely_ necessary if XML is to have any mass appeal.
Using a non-XML format (eg. DSSSL) flies in the face of what
XML is hoping to accomplish. I confess that I laughed out loud
when I heard that DSSSL was the chosen processing environment for XML.
(Purely for the fact that DSSSL isn't represented in XML, and not
for any other reason!)
A major advantage of XML representation is, of course, that you
can use your favourite XML editor as a stylesheet editor. The
daunting task of matching braces and finding syntax errors is
2) Is complementary to DSSSL
The proposal states explicitly that it is _complementary_ to DSSSL,
with the same "principles and processing model". This will help to
ensure consistent processing, regardless of its representation.
3) Is (predominantly) declarative
The programmatic nature of DSSSL is something that can severely
limit its appeal. Remember the "Is DSSSL Hard?" thread in
comp.text.sgml? My impression was that most of the folks who
answered "No" to the above question were people who were
hard-core programmers. I am such a person, but I would answer
a loud "Yes!". Maybe I've interacted with more non-programmers
and/or users. Nevertheless, since formatting is what most
novices start with, it is best that their tools be easier.
The common processing model should allow for easy migration
to DSSSL, if its greater power is desired.
3.1) ...while retaining programmatic features
Power is a good thing, so long as its presence doesn't
prevent simple things from staying simple. I think that
the scripting features of XSL are nicely unobtrusive.
4) Lets you reorder and restructure the elements
This is a _big_ plus. Most (all?) of the declarative formatting
environments that I've been exposed to don't let you change the
structure or sequence of the elements during formatting. When the
chapter number came after the title, you could never put it in
front of the title. The lack of such power may have kept a few
of us from using/designing declarative processing environments.
Not any more.
5) Has inline styles
This mechanism lets you specify formatting properties on the
element itself. This is a remarkably simple way of formatting
that _one_ element that has to be different from all the rest,
but whose context is too complicated or difficult to express.
Here's an example from the proposal:
Note that this is from the source document itself, and not
from an XSL stylesheet. Neat.
6) Supports named modes
A mode is simply a named formatting scheme. Only those rules,
etc. that apply to the current mode are used. This lets you
store rules for different presentations in the same stylesheet.
In their example, the "toc-mode" mode is used for a Table of
Contents presentation only, and the default mode is used for
the usual presentation.
This should also cut down on the duplication that usually
occurs when different stylesheets are used for different
presentations. It'll cut down on duplication errors, too,
because it is possible for most of the rules, etc. to
be centralized and shared.
7) Has a clearly-defined conflict-resolution mechanism
Some formatting environments specify that the "first"
applicable style in the stylesheet is always the one to
be applied. A stylesheet's behaviour should not change
based on the location of a style in the stylesheet's
source file. XSL will let authors organize their styles
in any way they see fit, with no effect on behaviour.
Some environments also allow _multiple_ styles to be
applied. Which ones, and in what order? Yuck!
XSL explicitly states that at most a single pattern
will be chosen. Good idea.
So much for my praise of a terrific standards initiative.
I have a few questions regarding the proposal itself, though:
- Some XSL tags seem to be mutable, in that they can be empty
or non-empty. The <target-element> tag, in particular, is used
both ways in the examples, eg:
<!-- EMPTY -->
. . .
<!-- non-EMPTY -->
Is this proper XML? Am I wrong in thinking that <tag/> is reserved
for tags that are _always_ empty? Is this just a notational convenience
within the proposal?
- The DTD contains (gasp!) an exclusion rule. What's going on here?
The fact that exactly one <target-element> should appear per rule
is something that the XSL application must enforce. I recommend
using a comment, instead, so that the DTD can eventually be valid XML.
All in all, I'm much more excited about the future of XML.
Sorry if this isn't the place to discuss this.
As usual, I can't end without an XSLvely bad pun,
PS - You can get the XSL spec at:
Russ Chamberlain - Software Developer
INFORIUM (The Information Atrium Inc)
Waterloo, Ontario, Canada
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (email@example.com)