W3C Recommends XSL 19
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."
XSL, XSLT, XML... (Score:1, Funny)
AC = Not Karmawhore (Score:3, Informative)
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 [docbook.org] 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.
I'm glad you found it simple, nobody else does. (Score:1)
XSLT is not based on rewriting the XML tree, but the correct way to view the process is on creating an output tree from an input tree. Rewriting would imply that elements that were not specifically analyzed (how ever you define it) would still be in the output tree. Also, you cannot reference the structure of the newly constructed output tree, only the input tree.
Using XML was supposed to free you of the burden of doing much of the parsing, i.e., have a consistent format for the data. However in XSLT you still have a very large parsing responsibility. They choose XML to represent the top-level transformation structures, but almost every element and attribute that has content has its own mini-language format. XML is too syntax heavy for a pure XML-only syntax, probably.
-j
XSL is truly a mistake. Beware. (Score:2)
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. (Score:3, Informative)
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? (Score:3, Interesting)
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? (Score:1, Insightful)
Representing the game of life in XSLT sounds difficult. I'm not sure if the language is intended for that type of thing (as you say, it was intended to fit 80% of the tasks).
I agree that DSSSL is much more elegant, but it's overkill.
Incidentally, in what situation was the problem you were having?
Re:Wasn't it supposed to be simple? (Score:1)
Re:Wasn't it supposed to be simple? (Score:1)
+-----+
|ooXXo|
|XooXX|
|XoooX|
|XXXoo|
|ooXXo|
+-----+
into this document:
+-----+
|ooXXo|
|oXooX|
|XoXoX|
|XoXoo|
|ooXXo|
+-----+
Replace the 'X's and 'o's with your favorite words.
They are both very regularly structured blocks of text with a few small precise rules. Why shouldn't a document conversion language be able to do this. Does you think that that mess of vague rules we can English would be any easier?
-j
< move along people. there's nothing to see here >
< something to placate the postercomment compression filter >
< these quotes stolen from Slashdot homepage >
< This page was generated by a Group of Trained Robots >
< This page was generated by a Team of Trained Geese >
Re:Wasn't it supposed to be simple? (Score:1)
Re:Wasn't it supposed to be simple? (Score:1)
-j
Re:Wasn't it supposed to be simple? (Score:1)
try
<myElement myAttribute="{Xpath Expression}"/>
All this and more at the excellent xls-list FAQ [dpawson.co.uk] where you'll find that XSLT has a strong user base and a wide range of mature implementations, ie competing on performance now rather than robustness or completeness.
But it really is different to non-declarative languages, so expect fun if you still enjoy learning.
Re:Wasn't it supposed to be simple? (Score:1)
When I posted, I was thinking of a particular time I needed to add an attribute to an element in the middle of a for-each. I remember it because it almost doubled the file size. One, of the many, relevant segments follows. Please, tell me how I am sucking. I am sure there is a better way of doing this (excure the t namespace, I use is because I am lazy):
<t:for-each select="//store/*/designer">
<a><t:attribute name="href">
<t:value-of select="url"/></t:attribute>
<t:value-of select="name"/></a></t:for-each>
Just as I inserted the "<a>" element, I was something as simple for the attributes. Since you treat a single tree and a forest the same when iterating over them, then why not for assignment, too?
Can I do this, hopefully, and have it constructe a forest of "a" elements?
<a href="//store/*/designer/url/text()">
<t:value-of name="//store/*/designer/name"/>
</a>
That seems to make sense, I hope: make "a" elements with "href" attributes, assigning "href" the text value of each "//store/*/designer/url" element. Take the value of all the "name" elements, placing them on the tree is the "a" element.
It would be the same thing that many other languages do with array assignment:
a[4 6 8 9 10]
meaning, do a scatter/gather assignment, giving the first 5 composite numbers the value of their largest prime factor.
(or imagine from c:
int a[0 3][0 3] = b[1 2][1 2];
assigning the corners of the 4x4 matrix to be the middle of another matrix)
-j
Re:Wasn't it supposed to be simple? (Score:2)
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.