RE: [xsl] Namespace wildcards

> > No, * has always selected all elements, in any namespace, 
> and will continue to do so.
> 
> So what's wrong with having a "Default namespace for wildcard 
> element names"
> static context? 

I think that what's wrong with it is that it's wrong for subtle "mode bits"
in the context to have quite such a dramatic effect on the language. People
are so used to reading "*" as meaning "any element" that if some context bit
changed its meaning to "any element in the default namespace", people would
end up staring very hard at their queries to find out why they gave
unexpected answers. And the benefit isn't worth it: I've never actually seen
anyone try to find "any element in the default namespace"; the gain isn't
worth the pain.

> 
> In any case, I suspect there's no going back and the
> pseudo-procedurality of XPath 2.0 will be a fact of life.
> No great shakes. If someone wants to use these features fine,
> if they want to use the procedural facilities of their language
> environment, that's fine too. The only real cost of these features
> in XPath is that it will probably increase the complexity of and
> reduce the number of fully compliant XPath 2.0 processors.

I was actually very pleasantly surprised when implementing XPath 2.0 in
Saxon how little it added to the existing XPath 1.0 code. The main work is
in supporting the increased number of data types, and the increased size of
the function library, and I think these changes are unavoidable. The
extensions to the grammar, such as "for" and "if" expressions, and the
generalization of path expressions, turn out to be very straightforward
(though I dare say there are lots of optimization opportunities that I
haven't yet explored).

Mike Kay

Received on Thursday, 7 February 2002 07:50:02 UTC