[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Microsoft's XSL Proposal
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@i... the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|