Re: Suggestion for XSLT 2.0

----- Original Message ----- 
From: Heiner de Wendt 

> I have to agree here. The current version really is far from being 
> intuitive, not to talk about fast&easy writing ;)  

... It is consistent with current Xpath principles ... 

My prediction is that current Xpath  principles will be 
anyway crushed when ( should I say 'if' ? ) XSLT will 
try to support DTD / Schema.

This is actually interesting. Omnimark moves from 
DTD-driven processing to  well-formed processing, 
XSLT moves from well-formed processing to DTD-driven
processing. 

<quote source="XSLT Recommendation">
G Features under Consideration for Future Versions of XSLT (Non-Normative)
The following features are under consideration for versions of XSLT after XSLT 1.0:
support for XML Schema datatypes and archetypes;
support for DTDs in the data model;
</quote>

Both products are moving to the same point:
"we should process XML document with or without  DTD" ;-)

( I could say "XSLT talks about Schema, not DTD" , 
but something tells me that this could change ;-)

Given with the speed of W3C ( and very fuzzy situation 
with DTD / Schema ) I think it could take long years for 
XSLT v 2.0  to appear  ;-)

Situation is really very interesting. 
-----------------------

1. If XSLT cares about more-or-less general XML transformations -
it can not ignore the fact that for many cases ( other than 
'rendering pages' ) there *is* a DTD/Schema of the 
'document-to-be-transformed'  and it could be *extremely* 
useful to use the knowledge about the structure of XML 
input ( In fact - the knowledge of Schema allows many 
critical optimizations on almost *every* Xpath construction. 
Yes - 'streaming XSLT' stuff again ;-)

This means XSLT will have to support DTD or Schema.

This means processing not 'one' XML input , but 'pair' =
XML file + Schema of this file ;-)

This means current Xpath could  crush.

2. If XSLT does *not* care about general XML processing -

<quote source="http://www.jclark.com/xml/xslt-talk.htm" >
Not for Everything
XSLT is not a general-purpose XML transformation language
XML can represent arbitrary data of arbitrary complexity
General-purpose XML transformation requires general-purpose programming language
</quote>

Who cares then? I have not found any sign on W3C website that
there is any effort to design a "general-purpose XML transformation
language". Does it mean that W3C really thinks that writing tons of 
C++ / Java / perl code  on top of DOM is the way to go? Hm... 

In this situation the very probable scenario could be that 
some big vendor ( not Omnimark ;-) may come out with some 
'general purpose transformation language for XML'. I only hope 
C# is not really prepared for that domain. But maybe C#  could 
be a good foundation for that 'general purpose transformation 
language for XML'. If this will happen - we'll get yet another situation 
when XML processing ( not a small area, huh? ) will be 
driven by one vendor. 

1.  Is the place of 'general purpose XML transformation language'
vacant?

2. Is XSLT addressing that place?

I guess this is a FAQ ;-)

Rgds.Paul.

PS. I think the letter is on topic with the subject.




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list