OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XPath/XSLT 2.0 concerns

[ Lists Home | Date Index | Thread Index ]

Paul Prescod wrote:
> Robin Berjon wrote:
>> I don't believe that either and I'd add that it takes a pretty narrow 
>> view on XML but I can in fact see use cases for having access to types 
>> in XPath. For instance when I see an XSLT processor chew for several 
>> minutes on a very predictable document (granted, it's Java based, but 
>> still) I think that if it had access to schema information it could 
>> optimize a lot of what it's doing by skipping entire subtrees.
> First, a "sufficiently intelligent" XSLT engine could optimize based on 
> the schema without necessarily changing any of the syntax and semantics. 
> i.e. it could do type inference-like stuff. That's not necessarily 
> practical but until someone has tried and has published why it isn't 
> feasible we should hold open that door.

Yes, that's one avenue of research that I will be exploring. However it 
doesn't apply as well to miscellanous XPath queries that may occur 
outside of the context of XSLT. XSLT was just an example here.

Again, I'm not saying that there *will* be a gain, only that there *may* 
be. If there isn't, be certain that I'll be dropping a mail to the 
comments list (though it may be too late).

> Second, if the document type is very predictable then maybe XSLT isn't 
> the best tool.  You could take your schema, compile it into Java classes
> or some equivalent for your favorite language, do some manipulations in 
> a language specifically designed for working with rigid structures and 
> then spit it out again.

That's not really an option for the category of devices that I work 
with, at least not for a number of members of that category (if only 
because we need to be portable). Also, it appears that people do want to 
use XSLT there because they know it and they like it.

> XQuery isn't far from being a transformation 
> language optimized for statically typed, rigidly structured data, but it 
> isn't sold that way.

I know, we're looking into it.

Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS