xml-dev - RE: transformations

[Richard Lanyon <rgl@decisionsoft.com>]

On Sun, 19 Nov 2000, Christopher R. Maden wrote:
> At 14:46 19-11-2000 -0800, Joshua Allen wrote:

> >This is a bit of an exaggeration.  XSL and XSLT were different activities,
> >and XSLT *was* primarily directed at transformation.

> When XSLT was split into its own specification, the intent of the
> XSL Working Group was made *very* clear that while it had other
> applications, the driving purpose of XSLT was to support
> transformations for styling, specifically that features that
> interfered with incremental rendering or side-effect-free-ness
> were not desirable.

Indeed, the Abstract of the XSLT spec says "XSLT is not intended as a
completely general-purpose XML transformation language", which seems
pretty clear to me.

The reasons why XSLT is not a general-purpose XML transformation
language seem to me to be the most interesting ones. Of course, I'm
biased, because I am in the process of writing a proper spec for a
version 2 of DecisionSoft's "XML Script" language, which IS intended
as a general-purpose XML transformation language (for an idea of where
I've got so far, there's an article in December's XML-Journal).

To a certain extent these do not seem to be me to be problems with the
overall capabilities of XSLT. It's difficult to know what is missing,
unless someone is seriously advocating that XSLT ought to act on the
post-schema-validation infoset (which would seem a bit odd, as you're
just about to change the document, presumably to comply with a
different schema, in which case you're going to have to
schema-validate all over). Yes, it's true that XSLT doesn't specify
conversions from legacy data, but otherwise you'd have to get XML
experts to write a spec for an XML language to deal with things other
than XML, which doesn't seem to me a recipe for success.

The most awkward aspects of XSLT to me are all those associated with
the functional programming, side-effect-free nature of it all. Now,
that could just be because I'm used to procedural programming, but I'm
sure I'm not alone in this, and I don't see that there's anything
about XML which particularly demands functional programming. XML
Script's major processing feature is that it takes lots of input
documents and "grafts" them onto an initially-empty data document
(they can then all be addressed using XPath) which is
VARIABLE. Commands can then alter this tree structure in place.

Of course, this doesn't help at all with the memory problems of using
an underlying DOM or DOM-a-like, but presumably this is the price you
pay for using a data language with more structure than flat text. Once
you have a tree structure, you're going to have to represent it
somehow and this will always have more overhead than a byte
stream. Isn't it?

-- 
Richard Lanyon (Software Engineer) |     "The medium is the message"
XML Script development,            |             - Marshall McLuhan
DecisionSoft Ltd.                  |