RE: [xsl] Namespace wildcards

> > + 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.

So what's wrong with having a "Default namespace for wildcard element names"
static context? As you correctly point an XPath language environment can avoid
backward compatibility problems with Xpath 1.0 by using XPath's silly assumption
about the "Default namespace for element names", namely no namespace (or the
null namespace). A "Default namespace for wildcard element names" static context
would allow an XPath language environment to be fully backward compatible by
making this static context be all namespaces (can we say "*"?) or it
could use a more rational (to my mind anyway) value like say the same
value as the "Default namespace for element names".

I suspect that there are probably more 1.0 applications that use a "*"
element name that would be busted by the introduction of data from
another namespace than would be busted by a different interpretation
of "*" so might be something that would be useful to control in the
language environment.

> 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.

This is kind of off topic for this list but I'd say this analogy
depends on whether you feel the Xpath evaluator is likely to be
tightly coupled with the language environment (certainly true for
XSLT and MSXML) or loosely as SQL usually is. A lot of SQL 3's
complexity derives from a desire to do as much as possible in
the SQL engine because of the overhead in communicating with the
procedural environment which, at the very least, is likely to be
in a different address space and quite possibly on a different
physical machine. There are also transactional integrity issues
which I don't think Xpath or XQuery are designed to deal with.

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.
C'est la vie.

Thanks

Alex Kodat
Sirius Software
Cambridge, MA

Received on Wednesday, 6 February 2002 16:31:35 UTC