W3C Recommends XSL

An Anonymous Coward writes: "The W3C upgraded XSL 1.0 to the status of a recomendation today, as they reported in a press release." From that release: "XSLT 1.0 makes it possible to significantly change the original structure of an XML document (automatic generation of tables of contents, cross-references, indexes, etc.), while XSL 1.0 makes complex document formatting possible through the use of formatting objects and properties."

Comments

AC = Not Karmawhore

[Anonymous Coward]

For those wondering,

XSL has two parts, XSL:FO and XSLT. XSL:FO is an XML format for the printed page. XSLT is a language for transforming one XML format into another.

XSLT is an incredibly useful language to learn. Imagine being able to take a Docbook file and spit out XHTML or XSL:FO > PDF, or... yes, even plain text.

For an idea of how easy it is I wrote a Docbook to HTML converter for 100 docbook tags in four hours, and I hadn't touched XSLT before.

XSLT is based around rewriting a data tree. You can step around the tree like a file system. In a hardcoded way like //html/body/h1, or relatively like ../body.

The language has loops and built in functions for analysing the tree. For example, how many times does a paragraph (p) occur in this HTML document when it's parent is a table cell (td)? count(td/p)

The downside is the bloated syntax. You know those horror stories about an XML programming language that looked like <xml:if(blah= blah)> do this </xml:if> ? XSL is that. But if you can get past that you'll find one of the most wonderful things for mangling XML into whatever format you want.

XSL is truly a mistake. Beware.

[Ars-Fartsica]

XML is a great technology for allowing systems that do not share a well-understood data interchange format to understand each other. Thats it. XML solves the interchange problem. This in itself is fantastic.

Applying this technolgy to page generation and tree transformation is not fantastic. This is what you get when you assemble the same gang of professional committee sitters that tanked SGML, and give them a blank slate.

Want to transform documents and render content? Try DOM and CSS. These are much simpler, more flexible, better understood technologies. CSS is actually supported by your browser, and DOM is actually supportedf by real programming languages.

Re:XSL is truly a mistake. Beware.

[cmowire]

Actually, there is some great usages for XSLT and XSL.

The thing that people are forgetting is that XSLT has been a W3C Rec for a long while. They are just recomending XSL now.

XSLT has many uses that just the DOM doesn't have. With XSLT, you can specify a smaller number of canned transforms to take a completely abstract set of XML tags to a viewable form in your browser.

An example of this would be an XML document to describe a program:
<PROGRAM>
<NAME>Blah</NAME>
<PLATFORM>Linux 3.0</PLATFORM>
<DESCRIPTION>This program sucks</DESCRIPTION>
</PROGRAM>

Now, tell me, what would a CSS style sheet to properly render this data look like? Sure, you can make the NAME, PLATFORM, and DESCRIPTION tags paragraph level and make them different colors, but that's not helping. With XSLT tree transforms, you can provide a relitively simple scheme for rendering things more like:
Name: Blah
Platform: Linux 3.0
Description: This program sucks

Now, you CAN do that in DOM, but then you will have to provide source code, most likely in JavaScript, to transform the tree. And then the users who surf with JavaScript turned off because all of the OTHER things it can do, like pop up windows at annoying moments, etc. XSLT just transforms XML documents, nothing more. Once we have good support for XSLT in web browsers, I suspect it will become a very useful tool.

Now, as for XSL, that's probably a good thing. Sure, there'll be a delay before people actually can handle the formatting objects. But XSL has a more complete formatting model that's useful for more than just webpages. I'm less familiar with it. I suspect they could have added similar functionality to CSS, but this way, your entire formatting process is usable just through transforming an XML tree. This way, you don't need to write all of the CSS parsing code, you just use your DOM. This also means you can embed XSL/XSLT code in a single XML file without any of that messy CDATA stuff.

Of course, I think that you could also say that making a whole formatting system around XML parsers is about as useful as making a whole OS around OOP messaging syntax. But the biggest generator of XSL code will probably be future word processors converting the style sheets to XML/XSL code.

Wasn't it supposed to be simple?

[Jayson]

After having used XSLT about a dozen times, I gave up. I had DSSSL expreience before, so I thought that it would be similar and that I could transfer some of my experience over. I felt like I was more productive in yacc or Antlr for quick projects and for anything that started to become more complex, I felt that the XSLT transformation definition complexity grew polynomially. For very large projects (more than a hundred million element, blame someone else for choosing XML for this, not me) I couldn't find a transformer that worked, even though I made sure that the DTD was regular (not context free).

I thought that the original goal was to make a _simple_ declarative language that handled 80% of the transformations easily and left the other 20% to something else (like using a real language). Even the simplest tasks require too much code in my opinion. My first XSLT project, a learning project, was to write the game of life, as it is with every new tool. I have two versions, the shortest being 150 lines that required the field to be an ugly composition of <o/> and <X/> elements.

There is a very high syntax to semantics ratio. Similar operations require different syntax, such as inserting an element can be done literally, but inserting an attribute requires special instructions (a minimum of 2 elements). There is no continuity in the different ways to reference a variable binding. You use templates to generate the structure of the XML but cannot generate text structure in a similar way, neither content data or attribute value data. Blah blah blah... I could go on. It seems like they ended up with a complex framework without strong expressive power. Why couldn't they just do DSSSL with the XML syntax if they wanted it?

Besides, for me it is difficult to look at with XSLT definitions/commands, obviously in XML, sprinkled around output literal XML elements. But I haven't trained my XSLT syntax eye too extensively. It is probably the same way people feel about looking at my DSSSL code.

p.s., I think they lie when they say it is side effect free and completely declarative.

-j

Re:Wasn't it supposed to be simple?

[Millennium]

I thought that the original goal was to make a _simple_ declarative language that handled 80% of the transformations easily and left the other 20% to something else (like using a real language).
No, that was CSS. XSLT was supposed to fill in another 15% or so, with only a small fraction then being left to a "real" language.