xml-dev - Microsoft's XSL Proposal

[Russell Chamberlain <russc@livepage.com>]

Hi,

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
       greatly reduced.

    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:

           <para xsl:font-weight="bold">

       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:

    <rule>
      <!-- EMPTY -->
      <target-element type="orders"/>
      . . .
    </rule>

    and later:

    <rule>
      <!-- non-EMPTY -->
      <target-element type="table">
        <element type="title"/>
      </target-element>
    </rule>

   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,

 - Russ

PS - You can get the XSL spec at:

    http://www.microsoft.com/standards/xsl/xslspec.htm

------------------------------------------------------
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 majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)