W3C home > Mailing lists > Public > www-xpath-comments@w3.org > January to March 2002

RE: [xsl] Namespace wildcards

From: Kay, Michael <Michael.Kay@softwareag.com>
Date: Wed, 6 Feb 2002 01:13:35 +0100
Message-ID: <DFF2AC9E3583D511A21F0008C7E6210602679C22@daemsg02.software-ag.de>
To: "'Alex Kodat'" <ALEX@SIRIUS.sirius-software.com>, "Kay, Michael" <Michael.Kay@softwareag.com>
Cc: www-xpath-comments@w3.org, zarella@hmmci.com, davidc@nag.co.uk
> Actually, it was based on the XPath 1.0 model:
> + if the QName does not have a prefix, then the namespace URI 
> is null (this is
> + the same way attribute names are expanded)
> whereas I see now that Xpath 2.0 says
> + Default namespace for element names. This is a namespace 
> URI. This namespace
> + is used for any unprefixed QName appearing in a position 
> where an element name
> + is expected.
> This is great and is a huge improvement over the 1.0 spec. A 
> teeny bit of
> a backward compatibility hit but well worth it and not likely 
> to affect anyone.

No, it's not a backwards incompatibility unless the host language chooses to
make it so. It would be incompatible if XSLT decided to set this item in the
XPath context from the default namespace declaration in the stylesheet, but
that's not what's proposed: instead there's a new default-xpath-namespace
declaration which is quite distinct from the XML namespaces. The idea is
that in the stylesheet you set


The default namespace for the source document and the result document will
generally be different.

> + A node test * is true for any node of the principal node 
> type.  For example,
> + child::* will select all element children of the context 
> node, and attribute::*
> + will select all attributes of the context node
> I assume that's in the default element namespace only?

No, * has always selected all elements, in any namespace, and will continue
to do so.
> Also, is *:* allowed? The spec doesn't preclude this but it 
> also is explicit
> about allowing NCName:* and *:NCName so this might suggest 
> that it's not?
> Seems like it may as well be allowed to me.

No, we don't want to allow *:* because it would mean exactly the same as *.
> I think a procedural language would tend to need a lot less from XPath
> than a non-procedural one like XSLT. Anyway, my argument was based on
> my mistaken belief that XPath didn't allow the host environment to
> have a default namespace.

That might be true; but as with SQL, I think it's desirable to do
declarative processing in the query language rather than procedural
processing in the host language wherever possible.

Mike Kay
Received on Tuesday, 5 February 2002 19:13:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:42 UTC