OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: transformations

[ Lists Home | Date Index | Thread Index ]
  • From: Wayne Steele <xmlmaster@hotmail.com>
  • To: paul@qub.com, xml-dev@xml.org
  • Date: Mon, 20 Nov 2000 11:00:42 -0800 (PST)

Hey Paul, Tell us what you really think!

It seems that a concensus is forming on this list:
    1. XSLT works very well for some tasks
    2. XSLT is terrible for many common transformation tasks

I'm sensing some bitterness from you about actually writing XSLT.
I too have been burned by (a) slow processing time, (b) no decent error 
checking, and (c) Microsoft's non-standard implementation.

But I really like the processing model of XSLT and I'm hopeful about all 
three of these problems:

   A. Slow processing time
      I have seen several implementations (MS, and I think Sun) of 
'compiled' stylesheets. This should be a big performance improvement, and 
should keep improving.

   B. No Decent Error processing.
      I remember c used to have the same problem. This is just a sign of the 
immaturity of the language. You've got XSLT processors, right? Now you want 
      This can be solved through better authoring environments (IDEs, or 
Pre-Processing Macros) and stylesheet validation tools. I think schematron 
would be a good choice for an "XSLT-Lint" application (apologies if that 
term is already in use).

   C. Microsoft's Non-Standard Implementation
      MSXML 3.0 looks to have pretty complete XSLT and XPath 
implementations. Non-Standard extensions have been pushed into the ghettos 
specified in the XSLT Rec. While this has been (and still is) a headache, I 
think they're to be commended for a smooth migration to the standard, 
following through on the promises they made from the get-go
(Disclaimer: I used to work with this team at Microsoft).

People who push XSLT to the limits I think know they're "using a wrench to 
pound a nail". But it does get the nail in, right? Who wants to learn (or 
invent, in this case) a whole new tool, when they can make the one they have 
work? Consider it a form of 'code-reuse'.

I suspect the end-all be-all generalized XML transformation solution is to 
be the forthcoming language from the XML Query WG. This would explain how 
long it's taking them to release a language - it's a hard, diverse problem, 
and they want to get it right. But I betcha (hope) they've benefitted from 
all of the XSLT implementation experience. And I'm sure XSLT will always 
have a place for the things it does really well.

-Wayne Steele

>From: Paul Tchistopolskii <paul@qub.com>
>I think this should be written explictly, because I found that almost
>any developer who starts with XSLT usually  forgets about the
>hidden cost of using XSLT for transformations. The hidden cost is RAM.


>In more general case. When trying to use XSLT for aggregation
>of some small document,  constructing that small document out of
>many big documents ( not the way XSLT was supposed to be used,
>I think ) - you may agian find that because of this bult-in all-in-memory
>pattern  XSLT simply can not cope with some of usecases.


>I can provide other particular cases when XSLT 'fails'. Anything sensitive
>to mistyping of one letter is the case, for example. XSLT is in fact 
>language with almost no guards against mistypings. Mistype one letter
>in any Xpath ( like it is "in any perl regular expression" ) - and pray 
>that you'l
>capture this error before it goes to production (if it resides in not 
>branch of the processing). And now imagine somebody modifying the code
>written by other person and mistyping the letter, or  ... sorry ... 
>We'l all see it soon, when XSLT will hit the market and armies of 
>will start writing tons of XSLT code ( not the case at the moment ).
>You'l not be given any warning ( and that's *impossible* to give that 
>without schema. When ( if ) they'l bring schema into XSLT I'l start 
>laughing and
>crying. I think nobody will ever use the resulting mix. That's why I've 
>writing my own mix (xml-linux).  Only  because I don't expect somebody
>will do this for me. I'm currently tired of debugging XSL. Some days
>ago I got tired typing XSL - and that gave XSLScript which increased my
>XSLT productivity by the factor of 3.
>This is why I say that XSLT is perl. XSLT is very close to ( curent ;-)
>perl in style and advantages / disadvantages they both provide.
>It is easy to write something in XSLT ( well, it took me 2 years to
>become really fluent in XSLT, so maybe it is not 'that' easy ).
>But it is hard to support complex code written in XSLT, because
>it lacks 'real' modularity, 'real' inheritance and some other things
>invented by some not so stupid persons for writing complex layered
>processing code ( AKA 'transformations' ).
>Hey, long years ago XSL was for rendering nice pages on web-client.
>XSLT was a part of XSL and it is good for that domain.
>Why should it be good for *any* transformation?
>How it *could* be good? It was not designed to be good for any
>Belive me, reasonable change of  XSLT processing model, syntax
>and some other things is possible ;-)
>XSLT processing model is really bright ( I'l say 'brilliant' ) step,
>but to me XSLT always was the first step, not the last one.


>This again means they'r using XSLT not for what  XSLT
>was designed !  To query repositories, we have XQL , not XSLT !
>I'm scared by the message which is sent by XSLT. It is *so* fuzzy.
>BTW -  take into account that MS XSL  is not XSL and many
>people  still think that this obsolete dialect implemented by
>'default' distribution of MS IE has something to do with 'real'

   [ending snipped]

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS