My first thought

For a mental image of XSLT, the first thing that sprang to mind when reading your post was the council chamber at the European Union, or the debating halls at United Nations.

If you've ever seen news footage of those places when a well supported debate is in full flow and seen the army of translators running around whispering on-the-fly translations into the ears of the delegates, observed the confusion on those delegates faces as they get miss-predicted or misinterpreted native language translation of the current speakers words, followed (hopefully) by the dawning of realisation as the translations are corrected in real-time. Seen their initial reactions of confusion or disgust turn to realisations of understanding and joy -- or vice versa -- then you may understand my mental picture.

I've seen various attempts at defining a common language for computer systems intercommunication that have been forthcoming over the years. Unfortunately, like Esperanto, nobody ever quite talks them the same way. Each native (proprietary!) speaker has the habit of imposing their own native dialect upon the basic structure and semantics of the language. Each tries to use and extend the use of the "common language" to incorporate and reflect the semantic variety, expressiveness and beauty of their own native language. The result is that they end up speaking as many dialects of the common language as there are native languages -- and often more, as each individual 'native-X' speaker tends to enhance their vocabulary in different ways.

A second view

For a second mental image, I go back to an unscheduled stop-over I made in New Delhi, India a few years ago. I was on a flight from Hong Kong back to the UK that was meant to touch down at New Delhi, re-fuel, exchange a few passengers and fly on. Four of the 16 main tyres on the jumbo jet burst upon landing and they didn't have replacements to hand, so we ended up being forced to spend the night and the following day in local hotels whilst replacements where flown in.

In most ways, this was a delightful and pleasurable experience as the hotels were superb, the cuisine excellent and the local people as interesting and friendly as they were diverse. There was one fly-in-the ointment. None of we transit passengers had the requisite visas for entry to the sub-continent, and so, for security reasons, our passports were taken from us at the airport prior to being bussed to our hotels. Theoretically, this meant we were confined to our hotels for the duration, but most of us found that a few English pounds or US dollars would hire us a taxi for the day, and we went out in small groups and got to see some of the local sites, markets and so forth. Great fun. The problem arose when we returned to the airport the following evening.

We were assembled in a large room in order to have our passports returned and to go through the customs and 'emigration' procedures. A very pleasant Indian Customs official, complete with a uniform that wouldn't have looked out of place on the Captain of the Titanic turned up after about an hour (a short delay by sub-continental standards:), and announced that he had our passports. Three, somewhat less resplendently dressed sub-officals came in with 4 large black bin bags containing the 300+ (from 20+ countries) passports. These were placed upon a large trestle table erected for the purpose and the official proceeded to reach into the first bag, remove a passport, open the cover and read out the name of the owner who was to move forward, be identified and retrieve their passport.

The problem was that with the nice officials fairly strong subcontinental accent, names (often phonetic translations) from 20 odd countries ranging from China, Malaysia, Australia & New Zealand through Abu Dhabi, Bahrain and Egypt, to Sweden, France, Greece, Spain and the UK, the pronunciations left something to be desired. Hearing and interpreting your own name when spoken by a non-your-language speaker is itself quite difficult, but when your surrounded by 300 other non-native speakers all questioning each other as to whether that last, staccato collection of consonants intermingled with sing-song vowel sounds was their name or not, it became incredibly confusing and difficult. It got worse -- much worse -- and the flight eventually took off some 5-hours later, but the rest of the story doesn't have relevance :)

I guess my point is that I've seen various attempts at providing a common, platform-independant mechanism for communications between systems, and so far none of them really live up to the hype. I fully understand the need for such an animal and support the aims, but the implementations leave so much to be desired. The problem is that you either end up with the lowest common denominator which results in complex and sophisticated systems talking to each other in terms of simplistic, verb-adverb-adjective sentences, which is a bit like a Russian and Chinese nuclear scientists communicating to each other via English baby-talk. Or you get a intermediate communications protocol that is so complex, as to allow the most sophisticated ideas and concepts from any proprietary system to be communicated to any other. A fully-defined, orthogonal and extensible protocol -- like XSLT.

The result is that every communicator has to implement detection and recovery procedures for every conceivable language construction, even if it will never use those constructions itself, or would be capable of processing them if it received them. That often leads to the situation where it becomes policy for companies and organisations to adopt such protocols "for all inter-systems communications", even when those systems are their own, similar, never-will-talk-to-the-outside-world, systems. This imposes a huge burden on both the development and runtime for these systems and can lead to dumbing down or castration of individual systems design, because the need to be able to translate all internal data structures and concepts into the intermediate protocol prevents unique and complex (but fitting) structures and concepts being used.

A final image

For a final image, imagine a brain surgeon trying to perform his trade using 30 foot long poles to prod the lower-lumbar regions of proxy-surgeons that enter commands on keyboards that control industrial robots that actually perform the brain surgery.

Trying to perform many of the types of transformations required by inter-systems communication -- date-format; numeric-format; case, codepage and language conversions etc. bits and bytes stuff that most computer systems handle easily and efficiently -- using a "program" written in XML, seems somewhat analogous :)

As you might have gathered, I'm not particularly impressed by XSLT. I see the need for it in some particular circumstances, but in 90% of cases, there is no need to divorce the logic from the underlying systems quite so completely. Most concepts in computers are transferable between individual systems without resorting to a protocol that is so far removed from the underlying mechanisms. For the 10% that do require such machinations, there has to be a better way. I don't know it yet, but I'm pretty sure it will be along some time soon :)

My conclusion is that you shouldn't resort to such mechanisms unless you have a real need to, and if you have, I commiserate with you.

Having now written a fair bit of XSLT, all I can say is that this is such a grandiosely melodramatic image as to be ridiculous. It’s as if someone was composing an intricately elaborate image of how writing Perl was like herding cats that chase mice running over wires in order to produce just the right line noise to get a working program – or some such absurd preconceived notion.

The problem is, I’ve never seen introductory material that manages to do proper justice to the language in its unmatched expressiveness and conciseness when manipulating XML documents. Most people get blinded by the superficial verbosity of the syntax as expressed in XML – which I hate as much as anyone –, and never realise the beauty and elegance of the semantics that the syntax expresses.

Makeshifts last the longest.

... its unmatched expressiveness and conciseness when manipulating XML documents.

You obviously haven't tried doing anything other than very simple translations and substitutions. Try doing something that expands one element into a number of element groups; or collating a large number of groups in order to produce summary statistics; and see any elegance (which I never perceived), and any pretence at conciseness disappear.

But mostly you are missing that an XML document is never the final form required by an application. Try loading a wordprocessor document from it's native (binary) format, and the same document from an XML representation and see how much extra time/cpu is used by the later. Same thing for spreadsheet data, and rdbms data, etc.

Try performing SQL type outer, inner or cross joins on tabular data held in XML format using XSLT. Then tell me that it is elegant and concise.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

If you want to stick with a tree analogy, you could think of XSLT as mechanism for whitewashing the trunk, tying on yellow ribbons, hanging Christmas lights, gathering nuts, and sawing it up for lumber - all in the chosen season.

More prosaicly, I think of it as a stylesheet mechanism. It provides a generalized "stringification" for the presentation of XML elements.

I could kind of grok XPath without resorting to visualization, but had to visualize trees to cope with XSLT. And for reasons probably anchored in exposure to antique CS texts, I visualize trees upside down (i.e., root at the top). So in this case the monkeys would be rearranging the tree while hanging on for dear life.

Someone, and I wish I'd saved the link, has a visual explanation of XSLT that draws trees from the top down, and color-codes the tree parts targeted and affected by various XPath/XSLT fragments. Just looking at things organized this way was enough to part the clouds enough to give me a grip on the big picture.

Some interesting responses there, for which I thank you.

I'm not sure I quite understand yours, pg. It's the kind of abstract stuff that makes my head hurt.

Does anyone have a mental mapping that they use with Perl/SQL code, (he said, widening the discussion a little)?

Do you for instance think of

<xsl:apply-templates select="item">
[download]

as

SELECT * FROM xml_document WHERE element_name = 'item'
[download]

and

<xsl:template match="item">
<p>
    <xsl:value-of select="." />
</p>
</xsl:template>
[download]

as

while(fetchrow-hashref){
  print '<p>' . $value . '<p>';
}
[download]

that kind of thing?

---




($_='kkvvttuubbooppuuiiffssqqffssmmiibbddllffss')
 =~y~b-v~a-z~s;                             print
[download]

Interesting... you know what, I actually had the same thought to compare XML with database and XSLT with SQL...

Actually there was (is) a XML query language defined, although I don't think it gained any serious attention.

More than SQL, which is just a set of command to manipulate the data in storage, XSLT is actully more similar to PL/SQL in terms of role.

To be quite frank, comparing with database, i am not in favor of XML at all, and have the feeling that XML will go away after a while (of course everything goes away eventually, but XML is not a very big success, in terms of technology).

Although XML is something new, but I can see lots of stuffs in it simply goes backwards.

Performance and bandwidth are two biggest problems with XML, and I strongly believe they are XML built-in. (Well one can always call something XML, even after it being foundamentaly modified *enhanced*, but to me that does not count)

What's your thought?

XSLT...

It's like baking a cake when you have empty cupboards and you have to run to the shops to buy each ingredient when the recipe calls for it.

So flexible that you can bake anything in the recipe book... But not exactly the most efficient way to do things.

So for example, you go to a plastic surgeon and show him several pairs of pictures. Each pair contains a photo of some feature on your body, and a photo of the same feature on someone else's body the way you want to look.

Unfortunately, the system isn't set up very well, and your photos get a little mixed up.

You feed those photos to a computer, lie down on the operating table, and pass out. A robot scans your entire body looking for things that look like any of the "before" pictures. When looking for your nose, it finds your nose, a small lump in your hair that coincidentally happened to resemble a nose, and your left elbow. It analyzes each one to figure out what part is the right nostril, what is nose hair, etc. It then proceeds to make each of those three places look as much like an ear as possible (that being the picture that got mixed up with your nose picture). However, it doesn't just carve an ear out of your elbow; it believes that it knows what part of your elbow was the bone in your nose and leaves it untouched, while ripping and tearing and rearranging other portions of your elbow so that they would look ear-like had they been the appropriate parts of a nose to begin with. As an end result, you end up with slightly messed up hair, an ear where your nose used to be, and a pulpy, bleeding mass of shredded tissue and splintered bone where your left elbow was.

ewwwww!

-theo-
(so many nodes and so little time ... )
Note: All opinions are untested, unless otherwise stated

Lurk awhile on the Mulberry Technologies XSL-List, and all will be clear.

XSLT may not currently be the fastest tool, but it works the way I think. But I always was a weird kid.

I visualize XSLT as a nude woman.

... come to think of it, I visualize everything as a nude woman.

Anonymously yours,
Anonymous Monk

Thanks again, everyone for taking part. I'm getting a faint, distant hint of an inkling that not everyone likes XSLT or even XML...

The reason I'm having to get to grips with it is that there are voices lobbying for XSLT to be used as the transformation language for the new Content Management System where I work.

It would of course be better than making up Yet Another Templating Language ourselves, but in most other ways I'm distinctly unhappy about it...

I'm getting a faint, distant hint of an inkling that not everyone likes XSLT or even XML...

XML is a fairly decent platform neutral way to express hierarchical data. XSLT is a decent way to express--again in a platform neutral way--transformations on hierarchical data. Performance is an open issue.

Martin Fowler has another take on XSLT. See http://www.martinfowler.com/bliki/MovingAwayFromXslt.html.

The really great thing about XSLT is that at least it's not DSSSL. DSSSL is basically Scheme with embedded CSS-like constructs. It, unlike the bagpipes, smells as bad as it sounds.

The really, really great thing about XML+XSLT is that you can just blat them at the client's browser and, for sufficiently correct values of "browser", you get rendered content. Transformation too slow? Get a proper computer, pal, it ain't our servers.

All markup and associate transformation languages suck; they, by definition, have to. After all, in order to fit your abitrary data into a structure that anyone else can understand, you've got to pack in a wheen of redundancy, convention and plain old hope to make sure the message gets through.

--
bowling trophy thieves, die!