Namespaces (Was: Re: [Xpath-ng] Thoughts on work products)

[David Rosenborg]

Hi Jeni!

> XPath 2.0 alters the way namespace nodes work -- namespace nodes don't
> have a parent element, which means that you basically end up with the
> same number of namespace nodes as you have namespace declarations
> (which breaks backwards compatibility but I think it's fairly rare to
> get the parent of a namespace node, so the break is fairly minor).
> XPath 2.0 also deprecates the namespace axis and provides functions
> for accessing in-scope namespaces instead.

From an implementation perspective, disconnecting namespace nodes is
a very good thing. And I think the benefits outweights the minor backward
incompatibility.

> If we allowed lists of lists then we could store namespace
> associations as lists of lists rather than as separate nodes in the
> data model. That could reduce overhead but doesn't get away from some
> of the sticky issues that namespaces raise.

I don't see how this would reduce overhead. Namespace mappings
are specific pieces of information that appears in every document so why
not have a specific construct for it in the data mocdel? I think that
using generic structures for this might actually increase overhead.

> I agree that a default namespace for element names leads to
> complications (because if you declare a default element namespace then
> suddenly you can't talk about elements in no namespace at all) but
> it's a usability boon, especially for novices. The default namespace
> for type names follows the same argument.

It leads to complications, but you could take the path the RELAX NG
compact syntax has taken by allowing namespace local = ""
and then local:foo. I'm not sure this is good in an XPath context,
but I think it works well in the RELAX NG  context.

> 
> The default namespace for functions is very different. It enables the
> built-in functions in XPath 2.0 to be in a namespace, but there are
> some sticky issues with that (for example if you set the default
> namespace to a function library that defines text() or node()
> functions -- the names clash with the node test names). Unlike the
> element default namespace, I'm not sure that it should be
> user-settable.

As I've indicated in an earlier post, I think a more elaborated function
library import framework a la Java could be a useful solution.

Cheers,
David