Where to Start with XSLT and XSL

Robin Johnson

I can't think of a better introduction than this - DaveP

Joe Kesselman kindly forwarded this, Crossposted from the newsgroup rec.music.filk with the author's permission;

David Carlisle et al.

Is that the reputation it has? I thought it had a rather different reputation, being easily the most successful of the W3C specified languages post XML, and one of the more widely distributed programming languages ever.

Odd. I find most people pick up the basic template driven style of xslt fairly quickly, It is true that people with more programming experience find some bits different/strange but that's because they just try to program in fortran with xslt syntax which doesn't really work, however people who haven't got preconceived ideas about programming normally pick up the programming aspects of xslt naturally as well (that being the point of the functional programming style, that it's more natural)

Michael Kay adds

These statements aren't contradictory. If XSLT weren't so successful, it wouldn't have any reputation at all, it would just be ignored like 99% of the other programming languages that have been invented. It's got a reputation for being challenging because people see the learning curve that's ahead of them and they know they can't just ignore the challenge, they have to face up to it.

I went up this learning curve myself about 4-5 years ago. I didn't find it easy. I never do find new concepts easy. I struggled when I first learnt SQL, when I learnt goto-less programming, when I learnt object-oriented programming - I even remember struggling the first time I had to understand subroutines. But each time, I've got to the top of the hill and never looked back. It's worth the climb.

Wendell adds

The bottom line is, a great deal depends, as when learning anything new, on your attitude going in. If you dread the prospect, it'll be hard. If you expect to have fun learning how to get things done with a powerful new instrument, it'll be easy. It's in the context of this awareness that I get bugged by all the claims of how hard XSLT is: that only becomes a self-fulfilling prophecy, for those unwary enough to believe it.

Didier Martin

In a previous life I wrote this: xml.com. This article explains the XML/XSLT process occurring either at the server side or the client side.

If you want to read more, just go to my personal site and read some of my articles I wrote about the XML technologies.

Didier PH Martin didier-martin.com

David Carlisle

Yes.

It bears some resemblance to the language under discussion (xslt) If we talked about "finding" nodes we'd have to say which xslt instructions found things, and which did other things, whereas teh xslt instructions that select have the syntax select-... the analogy with English is closer as well with select. for an Xpath like "/" you don't really need to "search" or "find" the root node of your document, you know where it is at the start, and it is handed to you as the initial node of the transform, however before you do anything with it, you need to select it with select="/" or specify code with a template that matches it with match="/".

That's the problem with making up your own terminoligy on the fly: you have to decide such things and then explain them to others before they know what you are talking about.

XML documents have elements and attributes. XSLT/Xpath data is a tree of nodes that more or less correspond to the original document. It is sometimes helpful to elide the distinction and sometimes helpful to stress it. Similar;y sometimes its helpful to stress "element node" and sometimes its more convenient to talk of elements. Sometimes (but rarely in an XSLT context it's convenient to talk of elementtags, which is something else again.

Yes I could guess (although I have not seen the expression before) But that was really my point. You are making assertions about the use of unfamiliar and confusing terminology which I just don't think hold up. When I looked at your message, just about the only terms in it that I was sure I understood were the Xpath expressions. If you are learning a new language then the terms are unfamiliar but that doesn't mean the terms are wrong and should be changed.

But it is a fact that the design of the language was explictly designed to be reminiscent of the unix and windows file path. We could not tell people that but we can't change history.

Much of the terminology comes from family trees; child:: following-sibling:: ancestor:: etc, however the syntax /a/b/* is just lifted straight from the shell file path syntax.

Yes this is true (If you mean what I think you mean) A single Xpath expression (as it selects a set of nodes, not just one) can represent many actual paths (branches) in the document tree.

not types of anything, just types. Xpath has the types number node boolean string XSLT adds result tree fragment, so that's 5 in all (plus one special object type for encapsulating any non standard extensions that a system might have)

If you start off with a document <x/> and transform it with <xsl:template match="x"> <y/> </xsl:template> then the first document <x/> is the input document and the result document <y/> is the result document. Exactly how the system does I/O is out of scope for the spec itself, but every system gives you some way of getting hold of the result, otherwise what's the point?

No. It seems you found an example where someone used a term not closely aligned with the terms in the actual specification which meant that without beeing given more context it's hard to be sure what exactly was meant. However you are arguing that technical terms be used less not more.

Roughly speaking it means that you declare what you want the result to be, not specify exactly how what the machine does to do it. "imperative" languags consist of instructions executed sequentially (mostly) by a machine.

Xpath is a search function, itjust searches (and selects) nodes in a tree or trees, XSLt is a programming language, you can express any algorithm in xslt that you can express in any other language.

XSLT list members.

This arose from the many questions that people ask on the list, to which the answer is that this is at time X, not time Y. Whilst the details may not be 100% correct, they hopefully provide some indication of what takes place when during the processing of an XML instance by an XSLT engine using an XSLT stylesheet.

Phase 0, XML parse of stylesheet and input document:

Build the internal model of the stylesheet (including URI resolution if needed) by parsing the stylesheet including any included or imported stylesheets.

Build the internal model of the source document (if present) Action document properties such as xml:space, xml:base etc See Note 1.

Phase 1, XSLT transformation.

Apply the stylesheet to the input document (if present).

URI and entity resolution for any doc() and document() calls from the stylesheet.

Parse additional entities such as the result of document() calls, Output may be produced at the implementors discretion

output production infers

Apply applicable document properties such as xml:space

Apply appropriate character encodings

Apply any character maps (XSLT 2.0) (See note 2)

Apply Disable Output Escaping.

Actual output target could be DOM Document or SAX stream or Serialised to a Disk file A feed to another transformation stage.

d-o-e impacts the serializer that writes the output to a file, not the processor that generates the output (the "result tree"). A reason it is optional is that serializers are optional, and if an implementor builds an engine with no expectation that the result tree will be written out to a file, how is it to be handled?

Note 1. (DC.) This may include some or all of the following in an appropriately interleaved order:

Note 2. The above three are only applicable when serializing using the XML, XHTML or HTML output method.

Mike Brown, as clear as ever, he really should be a teacher:-)

I've inserted this qanda here simply because I like it! DaveP.

Stop thinking about tags for a moment.

There are different ways of looking at XML. Yes, if you take the XML spec at its word, an element "is" the element start tag to the element end tag, and the element's content is everything in between.

However, you will have an easier time dealing with XPath and XSLT if you try not to relate these terms directly to the text of the raw document and its syntax. Instead, think of the text of the XML document, tags and all, as being instructions on how to build a hierarchical data structure -- a tree of "nodes".

Nodes are something that exist in an abstract (imaginary, implied) universe. Just think of them as "things"; little containers of information.

In the world of XPath/XSLT, the nodes are given relatively simple relationships to each other to form a hierarchical tree. Consider this tree:

The document element is a "child" of the root node. The text node and 2nd element node are children of the document element node. The root node is an "ancestor" of all the nodes. The element node is the "parent" of the attribute nodes, but in a twist of XPath and DOM weirdness, the attributes are not children of the element they apply to. You can see that an element is just one of several types of node.

Now consider that the node tree can be serialized into a linear syntax consisting of certain sequences Unicode characters:

These 'character' things are still a bit abstract, since computers need to ultimately deal with them as bit patterns (0's and 1's). So the characters are mapped ("encoded") into sequences of bits &amp; bytes according to a character-to-bit-pattern map that goes by a cryptic name like iso-8859-1 or utf-8 or one of a bazillion others. Once encoded as bits (or bytes or whatever the most convenient level abstraction is for you), your data is ready for storage and/or transmission in copper and silicon.

And that... is XML. It is up to you to figure out how to best arrange your data. Typically you use elements as named containers for other elements and/or runs of character data that become text nodes in the XPath/XSLT tree model. Attributes are name-value pairs that are attached to elements. When to use attributes and when to use elements is a matter for XML Zen 101.

You're off to a good start. You will also need to understand namespaces, what an XML parser does, and the XSLT processing model. Buy Michael Kay's XSLT Reference tome and pore over the introductory chapters.

Not necessarily wrong, but you should be thinking about trees, not tags, or you will be burned hard by XSLT. Check out what I just posted at http://skew.org/xml/stylesheets/treeview/html/ ... compare the sample_input.xml (view it in a text editor, not Internet Explorer, so you see the line breaks) and the sample_output.html. Then download an XSLT processor like Instant Saxon or msxml.exe, and start applying tree-view.xsl to your own XML documents.

The descendant and child axes do not include attribute nodes.

Michael Kay

A big question, but a good one. Trouble is, it needs a big answer, and I don't have time to give one.

It depends a little bit on the task you are performing, and the alternative approaches you are considering. Once you are over the learning curve, I think that an XSLT solution to most XML transformation tasks (the tasks for which the language was designed) will be shorter than solutions in other languages: that generally means they will be faster to develop and easier to maintain. A particular benefit is that if you use the rule-based programming model for XSLT, the stylesheet will be very robust in the face of changes to the schema of the source documents it is designed to process.

Don't believe arguments that XSLT is slow. For most straightforward transformations, the execution time is dominated by the time to parse the input and serialize the output, and that will be the same whatever language you use. For more complex transformations, very large input documents, etc, it's probably true that a good Java programmer could produce a faster solution: but could they produce it faster?

One shouldn't discount arguments based on skills and experience. Most people solving a programming problem will produce a better solution using poor tools that they know well rather than good tools that are new to them. If you're in a hurry, use the tools you know well. If you're taking a long-term view, don't attach much weight to the experience of your first few days.