Data types (Was: Re: [Xpath-ng] Proposal for definition of values/lists)

[Jeni Tennison]

Hi David,

>> The other thing that I've been pondering is whether we should have a
>> built-in expanded QName data type. I think that it might be really
>> useful, particularly for defining nodes (which have names that are
>> expanded QNames). I have a feeling that this will be contentious, and
>> of course how exactly a QName is represented is very problematic...
>
> Just as an anecdot: I once implemented such a data type in my XPath
> implementation. However, I can't remeber ever using it. Of course
> this doesn't mean it's a bad idea, just that for *my* uses of XPath
> to this date, the XPath 1.0 functionality has been good enough.
>
> But you've maybe found other benefits (such as notational, as I read
> your post).

The main reason that I think that having QNames as a core data type
would be a good idea is that it makes defining the data model easier.

For example, I'd like to say that a value has multiple types. Those
types can be represented as QNames, so the types of a value are a list
of QNames. If a value had just one type, we could do what the Infoset
does and say that a value has a namespace URI and a local name, but if
we want to support a list of QNames then we need to have a list.

I'll mention here that I'd also like to say that an element or
attribute has a *list* of names. This will give us easy support for
architectural forms and substitution groups. Again, if we do support
lists of names then we need to be able to support lists of QNames,
which means we need a QName data type in the core.

> How do you mean that the representation is problematic? Isn't it
> just a pair of two strings, the local part and the namespace URI?

Yes, well, the problem is that if you just hold the local part and the
namespace URI then you have trouble serialising the result because
there's no 1:1 mapping from a QName to a string -- the string you get
depends on the namespace declarations that are used.

In XPath 1.0, the name() function returns the QName for a node based
on the in-scope namespace declarations for the node itself.

In XPath 2.0, the current state of play is that conversions from a
QName to a string are just banned outright. I think this is too harsh,
personally, but the only rational set of in-scope namespace
declarations to use are those that are in-scope for the XPath
expression. And with that set, there's no guarantee that there is a
namespace declaration for the particular namespace URI that you're
looking at.

Another way out would be to have a QName include a prefix for the
QName. The prefix wouldn't be used when comparing QNames, but it could
be used when serialising them as strings.

Cheers,

Jeni

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