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 ]

Michael Kay wrote:
 > Unfortunately, while a lot of the type inferencing machinery is in place
 > to do it, the last few links in the chain aren't there yet. In
 > particular, it can only work in a template rule that is associated
 > firmly with a schema type. So long as you are allowed to construct
 > non-valid temporary trees and then process them using the same template
 > rules as you use for the source document, there's no way of knowing
 > statically what path expressions are guaranteed to be void.

Well, every node has to come from some source, and you should
be able to check whether the source tree is associated with a
schema you know or not (as are RTFs). This is then of course no
longer an optimisation but rather a feature for extended checks,
which hopefully can be turned off in order to gain performance.

Also, if a RTF construction does not contain xsl:element with
non-constant name, xsl:copy and xsl:copy-of, you could build a
syntetic schema. Even in the presence of some of the elements
above, you might be able to construct a schema which will
end in elements having ANY as children. In case of xsl:copy-of,
perhaps something from the tree the elements are copied from
could be used.

It is probably a nice intellectual exercise to build an XSLT
which takes a style sheet and creates a (partial) schema for every
xsl:variable and param.

What's the chance of getting "optimisation controls" into XSLT,
like marking templates as "apply only to input tree, raise a fatal
error if matching a node from a RTF" or "don't even try to match
a RTF node"? Not that I'd recommend such a practice.



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

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