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

[Uche Ogbuji]

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

By value you mean node?  Or do you mean that even non-node values would have 
multiple types?  If the latter, I'm uncomfortable with this for reasons I 
mentioned on XML-DEV: it is much easier for implementation, and usually a 
great deal more efficient to have such XPath values implemented using 
primitive types in the implementation language, which usually means one cannot 
further annotate those values.


> 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 would prefer that the equivalent names given by substitution groups 
and arch forms be available as an annotation defined in the appropriate 
modules.  I think the XML 1.0/XMLNS name should be foremost and distinct.


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

I would favor this latter approach.  I think keeping prefixes around can be 
hazardous, but we would plainly express the reasons and limitations here.


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
A Python & XML Companion - http://www.xml.com/pub/a/2002/12/11/py-xml.html
XML class warfare - http://www.adtmag.com/article.asp?id=6965
MusicBrainz  metadata - http://www-106.ibm.com/developerworks/xml/library/x-thi
nk14.html