The State of MathML : Mathematically Speaking (and Stuttering)
XML Namespaces : Universal Identification in XML Markup
The Emperor has New Clothes : HTML Recast as an XML Application
You are here: irt.org | Articles | Markup Languages | XSL - What's in it for us? [ previous next ]
Published on: Monday 15th June 1998 By: Janus Boye
Before we move onto talking about XSL, there are some acronyms, that we should get straightened out, before we begin:
Those acronyms are sufficiently complex that you may already be worried that this is Rocket Science, and you won't be able to figure this out, but don't panic.
XSL (Extensible Style Language) is a stylesheet language designed for the Web community. It provides functionality far beyond CSS (e.g. element reordering).
XSL is intended to be accessible to the markup level user by providing a declarative solution to most data description and rendering requirements. Less common tasks are accommodated through a graceful escape to a familiar scripting environment. This approach is familiar to the Web publishing community as it is modeled after the HTML/JavaScript environment.
With XSL, the family of XML specifications now include:
The proposal for XSL is still only a note at the W3C. XSL being a note means that it is not even a working draft yet, which implies, that there are still many issues in XSL, that needs to be discussed, and there will most likely be changes made to XSL, before it gets to be an recommendation.
In HTML, you can do just fine, without CSS, so why does XML need XSL? The reason for this is, that the display of HTML elements and attributes basically are defined by the HTML standards. Therefore a user agent (e.g. a browser) knows how to display an HTML document even if no style information is provided. An example of this is as follows:
<p>This is content in a footer</p>
In the above code, your browser would just pick the default font and size, and print the content within the P elements.
In your browser, this looks like:
This is content in a footer.
Then, consider this XML-example:
<footer>This is content in a footer</footer>
Now when someone looks at my document, they can better tell me the meaning of the string within the tags: it's represents a 'footer'.
Such descriptive mark-up, or "semantic" markup, is a key goal of XML. With XML, Web authors can now mark up their content or data "semantically", according to the meaning of data. Consequently they can better communicate the relevance of their content or data.
However, the manner in which the footer is laid out, is uncertain. Which font and size is chosen, and also how is the footer displayed? Is it displayed on the end of the document, or is it displayed on the end of each screen picture? Is it left-aligned, centered, or justified?
Therefore, some style information must be associated with an XML document in order to display it.
If there were two different browsers processing the element, chances are there would be two interpretations of the presentation in the element. Two interpretations of presentation usually results in a document looking considerably different based on each interpretation.
So while CSS2 finally provides a standardized presentation of HTML, along comes XML and, again, we are faced with the potential of chaotic and incompatible presentation styles.
This is where XSL comes in. XSL allows the author to apply formatting operations to XML elements. XSL is a language in which the author can indicate that the 'footer' element should be displayed as a paragraph, in blue and in italic using Arial. XSL is not the only way to display XML data. However, it provides you with a simple declarative solution. Also, because XSL syntax is XML itself, you don't have to learn a whole new syntax to begin writing XSL stylesheets.
With respect to CSS1, XSL supports all available functions, so that an accurate mechanical translation from CSS to XSL is possible. The difference between CSS and XSL is that while CSS is declarative and not user-extensible, XSL is primarily declarative, but is user-extensible using the ECMAScript language. XSL uses a XML notation, and CSS uses it's own.
To provide HTML authors a migration path and for HTML/CSS object compatibility, XSL provides a set of HTML/CSS core flow objects with HTML attributes and CSS properties as characteristics. For DSSSL core flow objects, CSS properties are mapped via flow object macros and script code to the appropriate flow objects and characteristics.
XSL provides all the advantages of a standard stylesheet language. It provides the advantages of seperating style from content, also it enables both authors/publishers and users to determine presentation of marked up data (even negotiation is possible!)
XSL builds on both DSSSL and CSS. DSSSL contributes with its basic formatting model, the idea of flow objects and a flow object tree, and a basic set of characteristics for those flow objects. CSS contributes some of its formatting properties, greater support for online presentation and interaction, and support for audio media.
The powerful capabilities provided by XSL allow:
The idea of SGML-encoded stylesheets is not new; in fact, it's been done many times before:
These stylesheets work well within their intended scope, and there's no doubt, that XSL's design will benefit from experience with these earlier declarative stylesheet languages.
Since XSL is very closely related to XML, it is like XML a very new technology. n August 1997 Microsoft, ArborText, and Inso submitted a joint proposal for XSL, in order to address the potential problems with presentation that arose with the specification of XML.
In November Docproc, the first XSL processor, was released. It can be used as a standalone converter or as a servlet, and was released by Sean Russell. It is written in Java, and uses a JavaScript-like language, Pnuts, instead of ECMAScript. Backends for HTML and for plain text are available; both DSSSL and HTML/CSS flow objects are supported and source is provided.
The W3C Working Group for XSL was then formed in January 1998, and after the XML'98 in Seattle, they announced, that they expected to have the first XSL working draft out in July 1998, and the proposed recommendation out in May 1999.
The XSL processor uses an XSL stylesheet to transform XML data into an HTML document. From the command line, the XSL processor is given an XML data file followed by an XSL stylesheet. It then takes those two files and uses them to produce an HTML file.
The content of the newly created HTML file comes from the XML data source; the display structure of the newly created HTML file comes from the XSL stylesheet. In processing the two files, the XSL processor examines the XSL stylesheet to discover which display structure applies to which XML source elements. As a result, the XSL processor creates a display structure that is driven by the content of the XML data source, and yet can be wholly independent of that source's structure.
The syntax for XSL is based on XML, and the display structures you will construct with XSL,¨will consist of many familiar HTML flow object. Learning XSL, therefore, does not require learning a new language. You can build on your existing knowledge of XML and HTML, enabling you to become fluent in XSL quite quickly.
Last, but not least, HTML is far from the only possible output format. XSL is designed to apply style independently of the output format. Thus a single stylesheet could be used to generate HTML; RTF, raw text etc.
The basic building block of XSL is the construction rule. A construction rule describes how a particular element is to be transformed into displayable output. The construction rule consists of two parts: a pattern identifying a type of XML source element and an action describing what to do with elements that match this pattern.
The following stylesheet is an example of an XSL stylesheet's basic structure. The stylesheet in this particular example has a single construction rule which displays the contents of a <footer> element as a blue, italic paragraph using Arial:
<xsl> <rule> <target-element type="footer"/> <P color="blue" font-style="italic" font-famliy="Arial"> <children/> </P> </rule> </xsl>
The pattern in the above case (<target-element type="footer">) "targets" (applies to) <footer> elements.
The action in the above case ((<P color="blue" font-style="italic" font-famliy="Arial"><children/></P>) indicates that the contents of the <footer> elements should be placed within a <P> element and that the <P> element should have the attribute style="color:blue;font-style:italic;font family:Arial".
An XML document, that used the above XSL rule could then contain the following:
<footer>This is content within a footer</footer>
The <footer> tag would then be rendered in blue italics using Arial.
The last thing, I'm going to be introducing in this article, is the concept of patterns and actions.
In the above example, you saw that the construction rule contains at least one <target-element/>. This <target-element/> identifies the elements from the XML source document to which the construction rule applies.
The most basic form of a pattern matches XML source elements of a certain type, without regard to the context of those elements.
Consider the following example:
<rule> <target element type="footer"/> <span font-style="italic"> <children/> </span> </rule>
The <target element type="footer"/> is here the pattern, that is combined with an action dictating that all elements that match the pattern are to be displayed in a italic span.
The <span font-style="italic"><children/></span> is then the action. More about the action in a second....
Often it is important to describe the element's context as well as its type. E.g. you may want the <footer> to be displayed differently depending on it's position within the document. For instance the frontpage footer might look different than the footer used on other pages.
So while there can be only one <target-element/> in a pattern (after all, the pattern identifies a single type of XML source document), there may be multiple <element/> elements, representing multiple levels of ancestors. The following pattern is valid, though unusual XSL:
<element type="book">
<element type="poems">
<element type="chapter">
<target-element type="footer"/>
</element>
</element>
</element>The above XSL-pattern matches the <footer> element of a <chapter> element which is a child of a <poems> element of a <book> element.
When a pattern identifies (or matches) a type of XML source document, the action portion of the rule is used to create the formatted output. The action describes what the output structure should be, what formatting properties to apply, and how to proccess the children of the source element.
The above example may seem trivial, but what we have just done is transformed XML, that is semantically marked up into a structure based on display characteristics. By just changing the type of the output objects and their style properties, we can generate very complex output using the same simple set of rules. In addition, as our documents get more complex, the same simple rules remain adequate to process them.
XSL has almost been around for as long as XML, but it seems to be off to a slow start. However, when a company -- or companies -- provide a proposal, they normally provide working examples, tools, utilities, or a prototype product to demonstrate the technology submitted with the proposal.
Microsoft, has provided both a command line tool, msxsl.exe, and an ActiveX control, and ArborText has provided a tool called "XML Styler", both of which demonstrate the use of XSL.
XML Styler is a free product, and it is one of the first products, that is helping us move down the path to real-world implementation of XML. It's purpose is to let Web-site producers easily create XSL style sheets, that will shape the presentation of XML content. Styler is written in Java, and at this time, it only works in conjunction with Microsofts Java VM, so you'll need Internet Explorer 4.0+ in order to work with it.
If XSL were a software program, the current version number would be something like 0.1. We're in the pre-alpha stage, of the program.
It might still be too early to reliably discuss XSL. When trying to look forward, XSL and CSS are likely to co-exist (just as HTML and XML are likely to co-exist), since they meet different needs. XSL is intended for complex formatting, where the content of the document might be displayed in multiple places; for example the text of a heading might also appear in a dynamically generated table of contents. CSS is intended for dynamic formatting of online documents for multiple media; its strictly declarative nature limits its capabilities but also makes it easy to generate and modify in the content-generation workflow.
Many pieces will have to fall into place before XML becomes a living, breathing technology. One such piece is a mechanism for rendering, XML-based material in a browser.
XSL is expected to be used where more powerful formatting capabilites are required or for formatting highly structured information such as XML structured data or XML documents that contain structured data.
Considering the lack of a solid specification, not to mention browser support, it might be a bit early to start converting the company site to XSL. Nevertheless, XSL is to XML, what CSS is to HTML.
If you're currently working actively with XML or plan to, you should also look into XSL -- become an early adapter -- and then give your data some style.
A proposal for XSL - http://www.w3.org/TR/NOTE-XSL.html
W3C Style page - http://www.w3.org/Style/XSL
Robin Cover's XSL page - http://www.sil.org/sgml/xsl.html
The DSSSL standard - http://www.jclark.com/dsssl
The stylesheet newsgroup - news://comp.infosystems.www.authoring.stylesheets
The State of MathML : Mathematically Speaking (and Stuttering)
XML Namespaces : Universal Identification in XML Markup
The Emperor has New Clothes : HTML Recast as an XML Application