What's the Big Deal With XSL? (Sections 5 and 6)
April 22, 1999
5 Internet Explorer 5 - A Flavor of XSL for the Desktop
It is exciting to have access to a developing technology early in its life, and the release last fall of Beta 2 of IE5, followed by the March 1999 release of the first complete version of IE5 provides it. The MSDN XSL Pages link to all the information required to work with the XSL support in this product.
Be warned, however, the Microsoft implementation of XSL differs from the W3C Working Draft in a number of places. In the Microsoft documentation suite the page http://msdn.microsoft.com/xml/xsl/tutorials/conformance.asp overviews Microsoft's assessment of the differences between the W3C Working Draft and IE5's implementation of XSL. With this page, Microsoft has an opportunity to keep us all up to date with discoveries of other differences not yet listed.
|
IE5 supports the W3C Stylesheet Association processing instruction for linking XML files directly to stylesheets. This requires the XML file to have the name of the stylesheet embedded. A new W3C recommendation I'd like to see developed is some kind of syntax for Universal Resource Locators (URL) that will encode the stylesheet association in the hyperlink. This would allow me to create a page with many references to a single XML file, each URL encoding a different XSL stylesheet with which to view the XML.
IE5 supports scripting in XSL, which can be very powerful when working with the Microsoft Document Object Model (DOM). Unfortunately, scripting hasn't yet been included in the XSL Working Draft, so any scripting written for IE5 will not work on other products. A number of built-in functions specified in the Working Draft are only implemented via scripting in IE5, thus most stylesheets will not be compatible.
You may have noticed in this article that I've chosen to use the suffix ".msxsl" for my XSL stylesheets for IE5. This allows me to distinguish files written for the Microsoft XSL engine from files written for engines supporting the W3C Working Draft, since (at least for now) they are always different. The Microsoft convention is to use the suffix ".xsl" for XSL files, but I find this misleading. I hope the differences in XSL implementation will all be gone when the final recommendation is released (we can always hope, can't we?) and then we wouldn't need to distinguish our stylesheets.
If there remain any differences in the transformation vocabulary or the semantics of the vocabulary as implemented by Microsoft, I hope (again!) that Microsoft consider distinguishing their custom semantics using their own namespace using something along the lines of:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl"
xmlns:msxsl="http://www.microsoft.com/msxsl"
xmlns="http://www.w3.org/TR/REC-html40"
result-ns="">
With the above declaration I could use <msxsl:eval> and <msxsl:script> (since such constructs aren't available in the 19981216 Working Draft) and <msxsl:apply-templates"> with nested templates (since the use of nested templates is not available in the Working Draft, which instead uses the mode= attribute that isn't available in IE5). By writing my stylesheets using two namespaces for transformation, I distinguish those semantics I expect from the Working Draft from those semantics available to me in IE5 without risking unanticipated portability problems by ambiguously using a single namespace. A new user might quickly recognize the first two constructs above as being unique to Microsoft, but may not recognize any nuances about the implemented differences to the W3C semantics for <xsl:apply-templates>. If it seems I'm harping on portability a lot, it is because I think it is incredibly important and could be a barrier to wide acceptance.
In this article I've chosen to write my stylesheet with a target of HTML constructs for both the ornamentation and information content, and CSS style semantics for rendering control. I could have chosen to have my stylesheet produce a target of XML constructs for the ornamentation and information content, and then use CSS style semantics for rendering control, but I was satisfied with the screen painting abilities of <DIV> and <SPAN>. Choosing HTML as my output also gives me an avenue to support HTML/CSS browsers not supporting XML by creating a static HTML/CSS file using the stylesheet.
5.1 The XMLNews Stylesheet Viewer
Recently, I have designed XSL stylesheets for XMLNews, a new initiative that includes a subset of the News Industry Text Format (NITF). I was excited to see what I could do with XML data files (files listing only names of other files, without prose or monologue) and stylesheets using IE5. For the XMLNews project I modified an HTML-based viewer to be triggered from XML using XSL stylesheets.
This snapshot of the XMLNews stylesheet viewer may be updated by the time you read this. New test files and test stylesheets are being created on an ongoing basis. Any updates to this viewer will be made available through the XMLNews web site. This example included with this article is only a preliminary release of a few example stylesheets, but the essence of the processing can be seen.
The viewer.htm file sets up the frames and displays the collections.xml XML file listing the collections of data files and stylesheets. Each XML file describing a collection of files is associated with an XSL stylesheet that renders the list of data files and the list of stylesheet files in two columns of a table. This stylesheet also has the scripting logic to load the given XML and XSL files selected into Microsoft DOM objects and render the one with the other, with the result going to the frame on the right of the canvas.
What was exciting about this was that once each of the stylesheets were written, I was then able to create collections of test files of XML and XSL and simply change the XML control files without needing to touch any of the stylesheet files.
For the electronic magazine appearances, I contracted an artist to create layout mockups in HTML for a given story. For each layout I stripped out the story content from the HTML, replaced it with XSL transformation vocabulary instructions, and wrapped it up in an XSL framework. The HTML I received from the artist became the example for my "transformation by example", and my job was to indicate where content belongs in the supplied example. Running the resulting XSL stylesheet on the XML data then accomplished the transformation of the content into a result mimicking what arrived from the artist, but for every story, not just the mockup she created for one story.
6 The Working Draft of the W3C Recommendation for XSL
I find it exciting that many features of the W3C XSL promote maintainability and flexibility in stylesheet writing. These features are in addition to the modularization of the logical and physical structures of the XSL files in XML syntax using XML features of general entities, external parameter entities and marked sections.
When writing a stylesheet, the additional use of XSL constructs for declared constants and macros (templates of stylesheet code with arguments) will allow the logical structure of the code to be compartmentalized and centrally supported.
Modularizing the Logical Structure
When sharing stylesheets, or creating multiple files to help with maintenance, XSL supports both including (logical tree insertion) and importing (ascribing precedence) of whole stylesheets. This leverages one's investment in stylesheets by allowing them to be reused in different scenarios.
Modularizing the Physical Structure
The next Working Draft promises to bring a number of new features to the transformation vocabulary, based on the experiences of those working with preliminary releases of XSL-based tools. The current vocabulary allows the stylesheet writer to explicitly direct the processing of nodes in the source tree on demand. In addition, one can set up node event handling for nodes and then submit portions of the source tree to the XSL engine for node event processing can be done when the order of the source tree nodes isn't known or the stylesheet needs to be flexible for alternative orderings (perhaps because the stylesheet is being shared by other stylesheets).
The ability to select the nodes for direct processing or for passing to the XSL engine for indirect processing gives the stylesheet writer the flexibility to order information by element type name, attribute name, or any node in the source tree. In addition, sort functionality instructs the XSL engine that the order of source nodes be sorted before being processed. With these basic controls information in the source tree can be traversed as many times as required to produce the desired result.
The 19991216 Working Draft describes a set of Formatting Objects and their semantics without, yet, being complete. It is acknowledged in the document that a future Working Draft will flesh out the details required for implementation and stylesheet writing. Nonetheless, the concepts (such as queues) are very interesting. Moreover, it is clear the designers of the semantics have a thorough understanding of the needs in this area. An editor's note in the document notes the committee is developing input to the W3C Common Formatting Model and is providing the semantic model in terms that XSL can be described.