xml-dev - Re: transformations

[Paul Tchistopolskii <paul@qub.com>]

----- Original Message ----- 
From: Gavin Thomas Nicol <gtn@ebt.com>

> > QUILT/XML-Query fill in somewhat where XSLT lacks as a transformation
> > language
> 
> Something similar that has been around for a number of years 
> is SGMLQL.
> 
> I think Simon has a very good point, which is that there are any
> number of different approaches to transformations, depending on
> exactly what one wishes to accomplish. For some things, XSLT
> is way overkill, for others, it's great.

... for some server-side things XSLT will simply don't work. 

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.

For example, I've failed to render some real-life financial reports, because 
as we all know, most of existing XSLT engines require loading the entire 
document into the memory, no matter how simple is the operation 
that you want to do with that document.  

In internal representations of XML file which are used by existing XSLT
engines, every XML node eats more than just a few bytes. 

When processing the document of 1 Mb in size and if producing the result 
document which is about 2 Mb in size, the amount of RAM required for this 
is not 3 Mb. It is much bigger. *Much* bigger. When using key() 
'for speed' ( looks reasonable to use key() only for *large* documents, 
right? ) - add some more RAM for building the in-memory index. 

saxon:preview allows to work this around for some cases, but 
saxon:preview is not XSLT.

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.

Yes, I know about some engines that try to address this problem
with ( different ) approaches. Sofar none of those engines are robust 
enough ( or fast enough ) comparing them to, for example, SAXON or XT.
When they'l be - we'l see. I'm talking about the current situation.

This is not XSLT criticizm. Saying that XSLT is good for it's problem domain 
but it is weak in some 'other' problem domains is not a criticizm. It is just 
obvious statement, I think. 

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.

I think there is one *huge* problem with XSLT.

I dont know how that happens, but XSLT message that W3C sends 
to the world is extremely fuzzy.

This results in people and some companies thinking and / or saying 
that "XSL is for any XML transformation".  Those who are making 
such statements are simply not understanding ( or hiding the fact ) 
that, for example, when their system is processing file of 100 Kb 
with some XSLT engine - the same system will never ever scale 
to process the similiar file of bigger size. 

Then I see some people talking something like : "yes, you're right, 
but what if we have the database behind the scene?" 

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.

I've wrote to XSL-list already, asking if it is possible for W3C to 
explain what is the *future* of XSLT. ( If it is supposed to 
become a general purpose transfromation language, or 
it is already general-purpose transfromation language, 
or general-purpose transformation language is not possible 
to create, so W3C will never bother about that language. )

Of course I got no answer to this question. I think they 
don't know the answer. 

I just wanted to say that there is *no* answers with XSLT.
There are questions only, I think. There is no point in 
"criticising XSLT". How can you criticise some silent creature
which has very messy 'yesterday' , some experimental 'today'
and almost unknown 'tomorrow' ? 

There may be some real point in criticizing XSLT v 2.0 ;-) 
Not earlier ;-)

Rgds.Paul.