Re: [xsl] is XSLT 2.0 implementable? (was: N : M transformation)

Subject: Re: [xsl] is XSLT 2.0 implementable? (was: N : M transformation)
From: David Carlisle <davidc@xxxxxxxxx>
Date: Tue, 4 Feb 2003 14:54:00 GMT
> If they were paying, either for the specs or for the products, then they
> might have more ability to influence the outcome...

It depends whether you view the W3C as a consortium of vendors
protecting their self interest, or an organisation that's 
"Leading the Web to its Full Potential".

Yes I know it's a bit of both but I'm still enough of an idealist to
believe that it isn't OK just to say that a specification can be taken
over by a group of database vendors and warped to their requirements at
the expense of the original users just because they are paying members of
the organisation that promotes the standard. Concerns of existing users
of a language should have weight when considering new versions of a
language, irrespective of financial concerns.

Actually I know that (despite appearences of the current draft:-) backward
compatibility issues _have_ been a major concern of the XSL WG. My
objection above is more with (one possible reading of) your comment than
wth the actual progress of the specification. However I think (in case
it isn't obvious) that in compromising over the merger with XQuery the
XSLT group has weighed the alleged benefits of the merge rather more
highly than the definite costs to existing XSLT users of additional
complexity and loss of predicatbility.

> Yes, this is likely. We're exploring this area at the moment: for
> example there are suggestions that a stylesheet should be able to say
> whether it requires to use a schema-aware (or non-schema-aware)
> processor, to ensure interoperable results.

yes please.

> Note that we already have this in a very basic form with ID attributes
> in XSLT 1.0; these will be recognized by the id() function or not,
> depending on the XML parser you use. 

I know. this and Microsoft's cavalier attitude to white space are the
two main causes of in-operability between stylesheets (not using
extensions). I would have hoped that the lesson learned would be to
tighten up such variability and try as far as possible to nail these
things down in a future spec, but no: rather than just have to worry
about ID attributes, now almost every element and attribute is subject
to the same variablity, and rather than worry about some white space
vanishing we can no longer be assured of any of the original lexical
information in the file being preserved. I'm sorry but I really don't
see this as progress especially as it is a price being paid for something
that I don't really think I need: the ability for an XSLT system to claim
that an XML view of a database is really an XML view of the original
document, even if all kinds of markup have been thrown away.
I don't mind these systems throwing away information that isn't relevant
to their use but that should be seen as some initial normalisation phase
out of scope for Xpath. XPath as a language for querying XML document
structure should do just that, not permit on-the-fly normalisations,
especially if it is processor specific whether or not they occur.


This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:

 XSL-List info and archive:

Current Thread