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

[David Rosenborg]

Hi Jeni,

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

OK

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

Hmm, I'm not sure what my feelings is about this at the moment
but I think it would be better if the data model was as close
to pure XML (XPath 1.0 I guess) as possible but with room for auxiliary
information. That is, I'd prefer a single name for a node, but for supporting
for example substitution groups, you could have an extension axis gear name
matching to another property than the name property. So in addition
to the principal node type, you would have a principal name property,
which could possibly have a list of names. But I'd leave the original
name property unmodified  (modulo using a QName type for the value)
or at least only allow a singleton list.

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

Yes, this is a problem, but I don't think it's a problem specific
to a QName type. As you say, the problem appears when
you want to get a prefix for a name (for example when
serializing nodes) but if the local part and namespace URI
are supplied as two separate strings or in a compound
QName value doesn't really change anything in that regard.

Cheers,
David