xml-dev - transformations

["Simon St.Laurent" <simonstl@simonstl.com>]

I'm pondering the state of transformations in XML while preparing a
presentation about 'transformations as a way of life', and I'm coming to
the conclusion that we've oversold a few tools to the detriment of other
possibilities.

One of the finest moments I've seen on any XML-related mailing lists was
James Clark's discussion of the limitations of XSLT on XSL-list over a year
ago:
http://www.mulberrytech.com/xsl/xsl-list/archive/msg04455.html

It's definitely best to read the whole message, but if you're in a hurry,
he notes that XSLT is better at going from more structured data to less
structured data, better at structure-based transformation than
content-based transformation, and better at trees than graphs.

I was also pleased to see him say "I would never claim that XSLT is the one
true transformation language for XML."  This wisdom doesn't seem to have
percolated very far, however, since I've edited a number of books which
hadn't seemed to notice and constantly find conversation where
transformations are presented starkly as a choice between XSLT and DOM
processing, with one choice or the other given preference.

When I hear these discussions, I sometimes interject with suggestions about
SAX filters, architectural forms, Omnimark, and even (gasp) regular
expressions.  Lately I've been thinking about using RDF to map
relationships among vocabularies, though mostly I've got some pictures
rather than RDF documents.  All of these possibilities have merit, and all
of them receive some use in XML processing.

For some reason, however, these ideas haven't really picked up mindshare.
I find it somewhat ironic that 'style sheets' are now proposed as a tool
for large-scale conversions during conversations between businesses, and
even that a technology whose roots were in Dynamic HTML has grown into a
primary interface for manipulating XML documents.  These tools have done
extraordinarily well in solving a lot of problems, but there are large
classes of problems they solve inefficiently at best, some of which are
very very simple.

My favorite case is simple translation of element names, where markup needs
to be presented to the user in his or her native language.  While many
technologies are capable of doing this, making it work is pretty tricky
when multiple languages are involved.  There's no unifying dictionary
mechanism for querying 'is-a' relationships by language keys.  Instead,
there are a lot of different ways to transform one element to another and
preserve the content along the way.

Jonathan Borden showed off some very cool work at XMLDevCon 2000 which got
me thinking about these issues more deeply. I've been pondering the RDF
modeling simply because it seems the easiest to manage and extend over the
long term, but it's still just pondering at this point.  

I'm not sure these are problems we can solve any time soon, or easily, but
it's interesting to see that we may just be getting started.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books