Re: is XSLT 2.0 implementable? (was: N : M transforma
> 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. David ________________________________________________________________________ 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: http://www.star.net.uk ________________________________________________________________________ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
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