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

[Jeni Tennison]

Hi Uche,

>> I have no solution, but -something- to make working with namespaces
>> easier.
>
> Agreed. Mike Brown and I just yesterday ran into the old XSLT trip
> wire:
>
> "The xsl:exclude-result-prefixes and exclude-result-prefixes
> attributes apply only to namespace nodes copied from the stylesheet
> using literal result elements. They do not affect namespace nodes
> copied from the source document using <xsl:copy> or <xsl:copy-of>;
> there is no way of suppressing these." -- Mike Kay
>
> It just illustrates what a fragile conception namespace nodes and
> the whole XSLT/XPath machinery 1.0 is.
>
> That having been said, is there any way to fix this and maintain
> backwards compatability?

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.

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.

One of the biggest complications with namespaces and namespace nodes
is prefixes in content -- if you have prefixes in content then you
can't know which namespace nodes are required and which can be ignored
or omitted.

Another complication is that as currently designed the XPath 2.0 data
model (and the Infoset) make it hard to have stand-alone attributes.
Of course stand-alone attributes can't exist in serialised XML anyway,
but it's sometimes useful to create a set of attributes that you copy
onto several elements rather than having to create a dummy element to
hold them.

>> Once a week we get mail from someone who wonders why their XPath
>> doesn't work, since they use the same ns-prefixes. I see the value
>> maintaining separate prefix->uri mappings for the XPath apart from
>> the documents to which they are applied, but it causes headaches.
>> 
>> Bare-minimum, default NS for xpath exprs would rock.
>
> Hmm. Here be dragons, I think. I think allowing default would make
> things even more sneaky in some cases.

In XPath 2.0 there are two default namespaces -- one for element and
type names and one for function names (I think that there's agreement
that there should be three -- for elements, types and functions, but
it doesn't look as though that made it into the most recent draft).

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.

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.

The default namespace for types also plays a role; in XPath 2.0
there's a bit of a weird situation where you can refer to a type
without a prefix when it's obvious that you're talking about a type
but not when you're doing a functional cast. This means that:

  cast as language($lang)
  xs:language($lang)

do the same thing, but:

  language($lang)

would cause an error (because there's no function called 'language').
That's really an issue about how you do casts and constructors --
XPath 2.0 only has this issue because it has a functional syntax for
casting and constructing values.

What I think we should do is say that each module defines its own
namespace for the functions, node tests, axes and so on. Then a
profile should pull modules together under a profile-level namespace
and define how any clashes between them are resolved. A profile (or a
module) might also define a default default type namespace if there
were particular types that were useful to the module.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/