This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Suggestion for XSLT 2.0
- To: xsl-list at mulberrytech dot com
- Subject: Re: Suggestion for XSLT 2.0
- From: Paul Tchistopolskii <paul at qub dot com>
- Date: Sun, 10 Sep 2000 23:37:57 -0700
- Organization: The Qub Group
- References: <53B2164F2C@systec.de>
- Reply-To: xsl-list at mulberrytech dot com
----- 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