QName URN scheme

Apparently, Rich Salz and Dave Orchard are working on a URN scheme for QNames (via Tobbi). Read on for my thoughts on this proposed scheme.

This kind of approach has been suggested a number of times before (I don't remember who did that suggesting, though) and my major complaint is that this generic way of turning QNames to URIs disregards the fact that QNames are typed. In reality, a QName can be used to identify an XML element, XML attribute, XML Schema element or attribute declaration (these two may possibly be unified with the previous two), XML Schema type, WSDL interface, WSDL service and many other things, and just from looking at a QName we don't know what it is supposed to mean.

The proposed scheme takes the stance that one resource can be both an XML element, XML Schema type and WSDL interface. The existing ways of turning QNames into URIs outside of RDF (c.f. XML Schema Component Designators and URI References for WSDL constructs, for RDF see the last paragraph of this post) result in long and possibly user-unfriendly URIs that are unambiguous in what they identify.

At first, I didn't like these long URIs and I also thought that one resource can have multiple orthogonal aspects (XML Schema type, WSDL interface) but nowadays I believe that this is more confusing than useful. In effect, if the QName URN scheme (or something similar) becomes standard, it will effect in a good practice of not using same QNames (as in same namespace and local name, disregarding the prefix) for different constructs, leading to the policy of, let's say, prefixing the local names with type identifiers, like ns:ifaceStockQuote and ns:typeStockQuote for a WSDL interface of a stock quote service and the XML Schema type of an actual stock quote. I don't like such "good practices" and policies.

Dave writes on his blog that there is no single way of turning QNames to URIs, but I don't see the requirement. According to the TAG finding on the use of QNames as identifiers, where there is a compelling reason to use QNames instead of URIs for identification, it is imperative that specifications provide a mapping between QNames and URIs. Therefore whenever we see a QName being defined, we also know from the language spec what URI it means, and those URIs will likely not have the ambiguity problem (judging by the XML Schema and WSDL solutions). We don't ever really see a QName without knowing its type (and the associated algorithm for turning a QName into a URI).

So basically, I think that while it's very simple, the proposed QName URN scheme leads to harmful ambiguities in the meaning of URIs.

As for RDF's use of QNames, they use them as a shortcut for URIs. They basically start from URIs and in the XML syntax turn them into QNames for the dubious readability benefit, whereas elsewhere they use relative and base URIs for the same URI-shortening effect. They don't create QNames to identify things, they create QNames to represent (almost arbitrary) URIs, and the proposed QName URN scheme goes in the other direction, therefore there's less connection between the two than Dave implies.

Posted at 1508 on Tue, Dec 21, 2004 in category Ideas | TrackBack | Comments feed

Comments

Hey Jacek,

The ambiguity is already there; every identifier need to a context of applicability; a bare URI might identify any kind of Web resource, and it's only when it's contextualised -- e.g., with a href attribute, an img element, an xmlns attribute -- that will you know what to do with it.

The fact that a URI scheme doesn't tell you the type of what's on the other end is a feature, not a bug.

The problem with not having a normal way to turn QNames into URIs is that different specs that want to identify the same things might use different algorithms for shifting between them, and therefore be incompatible.

Posted by: Mark Nottingham at December 25, 2004 9:49 PM

Mark, I agree that how a resource will be used is a matter of the context, but what the resource means, what it is, does not depend on context.

The problem is when two languages attach, lets say, a description to a single QName, for instance the purpose of an element and the description of an interface. Of course these descriptions will differ. When the knowledge is combined, according to DaveO's approach we'd end up saying that this QName has both descriptions. This would be confusing at best.

And the problem you mention should not occur because WSDL, when reusing XML Schema type QNames, will use XML Schema's way of turning those QNames to URIs, whereas WSDL's QNames will be turned to URIs using WSDL's algorithm.

Posted by: Jacek at December 30, 2004 12:07 PM