Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

W3C Recommends XSL

timothy posted more than 12 years ago | from the wheels-grinding-slowly dept.

The Internet 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."

cancel ×

19 comments

XSL, XSLT, XML... (1, Funny)

Anonymous Coward | more than 12 years ago | (#2439471)

I won't use any shit that I can't parse with fscanf.

Re:XSL, XSLT, XML... (0)

Anonymous Coward | more than 12 years ago | (#2460556)

I won't use any shit I can't parse with stone knives and bearskins.

AC = Not Karmawhore (3, Informative)

Anonymous Coward | more than 12 years ago | (#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 [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. (1)

Jayson (2343) | more than 12 years ago | (#2440133)

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.

-j

Sarcasm. (0)

Anonymous Coward | more than 12 years ago | (#2440199)

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.
URL?

XSL is truly a mistake. Beware. (2)

Ars-Fartsica (166957) | more than 12 years ago | (#2439865)

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. (3, Informative)

cmowire (254489) | more than 12 years ago | (#2442438)

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.

Re:XSL is truly a mistake. Beware. (0)

Anonymous Coward | more than 12 years ago | (#2452530)

XSLT can be ugly but using XPath to select XML nodes is far easier than drilling down into the document with DOM.

Re:XSL is truly a mistake. Beware. (0)

Anonymous Coward | more than 12 years ago | (#2456031)

the only real programming language
remains nowadayz C++ , everything else that was
programmed in something else and worths something
was rewritted in C++... if you're meaning WEB,
then say so... don't say real programming languages

Wasn't it supposed to be simple? (3, Interesting)

Jayson (2343) | more than 12 years ago | (#2440083)

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? (1, Insightful)

Anonymous Coward | more than 12 years ago | (#2440271)

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?

Re:Wasn't it supposed to be simple? (0)

Anonymous Coward | more than 12 years ago | (#2448604)

My (yep, me again) simplistic Docbook to HTML transformation took twenty lines. This converted H1-H6, P, LI, Tables, Images, Links, and em/i.
So what you're saying is that this guy is an idiot? Yeah.. seems so.

Re:Wasn't it supposed to be simple? (1)

gilmae (123361) | more than 12 years ago | (#2444126)

You tried to implement the Game of Life in a data transformation language? Why? Did you implement a browser in COBOL?

Re:Wasn't it supposed to be simple? (1)

Jayson (2343) | more than 12 years ago | (#2444525)

Data transformation, isn't that all the game of is it? I want to munge well structured text. I wanted to transform this document:
+-----+
|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? (1)

gilmae (123361) | more than 12 years ago | (#2445970)

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.

Re:Wasn't it supposed to be simple? (1)

Jayson (2343) | more than 12 years ago | (#2449748)

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.

-j

Re:Wasn't it supposed to be simple? (1)

roundand (145497) | more than 12 years ago | (#2449737)

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

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? (1)

Jayson (2343) | more than 12 years ago | (#2449950)

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"/>
</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] := 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)

-j

Re:Wasn't it supposed to be simple? (2)

Millennium (2451) | more than 12 years ago | (#2450077)

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.
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...