[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: transformations
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. |
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|