Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: transformations
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
XSLT-Lint?
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@q...>
>
>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.
[snip]
>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.
[snip]
>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
>'write-only'
>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
>obvious
>branch of the processing). And now imagine somebody modifying the code
>written by other person and mistyping the letter, or ... sorry ...
>nevemind...
>
>We'l all see it soon, when XSLT will hit the market and armies of
>developers
>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
>warning
>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
>started
>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
>transformation.
>
>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.
[snip]
>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'
>XSL.
[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
http://profiles.msn.com.
|
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
|
|||||||||
