Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Trust the World's Fastest VPN with Your Internet Security & Freedom - A Lifetime Subscription of PureVPN at 88% off. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×
The Internet

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."
This discussion has been archived. No new comments can be posted.

W3C Recommends XSL

Comments Filter:
  • by Anonymous Coward
    I won't use any shit that I can't parse with fscanf.
  • AC = Not Karmawhore (Score:3, Informative)

    by Anonymous Coward on Tuesday October 16, 2001 @09:35PM (#2439539)
    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.

    • It took me a whole weekend to write Conway's game of life for my first learning project. My first real application was a simple xml logical to HTML converter. It took about 12 hours. The real catch was when I needed to ouput to be dependant on two different far away element bodies.

      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.

  • 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.

    • 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:
      <PLATFORM>Linux 3.0</PLATFORM>
      <DESCRIPTION>This program sucks</DESCRIPTION>

      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.
  • by Jayson ( 2343 ) <`jnordwick' `at' `'> on Wednesday October 17, 2001 @12:56AM (#2440083) Homepage
    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.

    • by Anonymous Coward
      My (yep, me again) simplistic Docbook to HTML transformation took twenty lines. This converted H1-H6, P, LI, Tables, Images, Links, and em/i.

      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?

    • You tried to implement the Game of Life in a data transformation language? Why? Did you implement a browser in COBOL?
      • Data transformation, isn't that all the game of is it? I want to munge well structured text. I wanted to transform this document:
        into this document:


        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?


        < 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 >
        • I've only read about how to use XSLT, not actually used it myself, but nowhere in my readings did I notice anything about changing the data you are transforming, just changing its form. From XML to, say, HTML, or plain text, or csv.
          • How is transforming "" to "" different from transforming "o" to "X"? The biggest problem I had in XML on my first real project was spending an hour trying to output "There is 1 email message unread. Would you like to read it?" and "There are 12 email messages unread. Would you like to read them?" in some templatized way. You know, being dense: "There W X email messageY unread. Would you like to read Z?" Then I just hardcoded all the necessary strings (about half a dozen of them) and wrote the read/unread message totals in a scorebox. Screw english. Similar to the typical i18n hack people use for error messages.

    • but inserting an attribute requires special instructions (a minimum of 2 elements)

      <myElement myAttribute="{Xpath Expression}"/>

      All this and more at the excellent xls-list FAQ [] 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.
      • Hey, I didn't know that. Nice.

        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"/>

        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] := 2 3 2 3 5

        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)

    • 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.

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson