- From: Harry Halpin <hhalpin@ibiblio.org>
- Date: Fri, 09 Jun 2006 10:36:41 +0100
- To: mark.birbeck@x-port.net
- Cc: www-tag@w3.org, public-rdf-in-xhtml-tf@w3.org
I think Henry's pointing to the conceptual problem with making CURIEs a "superset" of QNames. Unlike CURIEs, QNames (at least as I've been able to discover, correct me if I'm wrong - the spec just seems silent) do not define an algorithm for converting an entire QName to a IRI, and by "algorithm" we're not talking about anything fancy - but just concatenating the namespace URI and the local name as strings, which is what most processors do anyways - as pointed out by Borden [1] and raised to the TAG [2], who seemed to be answer a sort of different question in their finding. Yet a processor can map (expanded name, local name) like (http://www.w3.org/1999/XSL/Transform,template) to an IRI by doing: http://www.w3.org/1999/XSL/Transformtemplate Or by doing: http://www.w3.org/1999/XSL/Transform#template And it seems both would be equally valid or invalid, depending on your opinion. So by making CURIEs a superset of QNames is a bit difficult as long as the QName (namespace prefix, local name)=>IRI construction is unspecified. And so using the ":" for QNames and CURIEs means that given any "x:y" element or attribute name one couldn't tell whether one meant an IRI or a (namespace prefix, local name). So there seems to be two choices: 1) Unspecified IRI construction for the entire (namespace prefix, local name) a *bug* in QNames and should be corrected post-hoc by the CURIE proposal. If this is the case, then CURIEs should use ":" and then make themselves a superset of QNames. or 2) Unspecified IRI construction in QNames is a *feature* and so CURIEs should exist as a parallel standard, and so use [insert character besides ":" here] in order to keep confusion between QNames and CURIEs at a minimum. My earlier post is that some communities (i.e. some of the microformat people I talked to at WWW2006) mentioned that they would like another character besides : for "namespaces in microformats." Next time I'll just tell them to escape their colons :) [1] http://www.openhealth.org/RDF/QNameQuagmire.html [2] http://www.w3.org/2001/tag/issues.html#rdfmsQnameUriMapping-6 Mark Birbeck wrote: > > HI Henry, > >> My initial reaction is similar to Stuart's -- there's a lot to agree >> with here, but >> >> 1) I think we do better to keep QNames (shorthand for an *expanded >> name* which is a pair of an absolute IRI and an NMTOKEN local >> name) and CURIEs (shorthand for an IRI) clearly distinguished >> conceptually; > > Great...I've constantly tried to emphasise that my first motivation is > to 'unpollute' QNames. The syntax is secondary--it's the fact that > QNames represent XML elements and attributes, and yet have been used > in numerous places as a shorthand for URIs, that I object to. > > (I'm not the first to have objected, of course! People involved in > early RDF work were also aware that using QNames for predicates was > dodgy, but they reluctantly went ahead in the absence of an > alternative.) > > >> 2) We think seriously about an alternative to the ':' as the >> separator for CURIEs. > > Firstly, I think that horse has bolted. The ':' is used in all sorts > of places to indicate scoping, not just QNames, precisely because it > feels so natural. It's used in URN values, in IPTC subject codes, and > so on. > > Secondly, and more importantly, I'm proposing that many current uses > of QNames should actually be CURIEs, and we therefore need to ensure > backwards compatibiliy. For example, in your own work, Henry, XML > Schemas should not be using QNames to identify datatypes for use in > other langauges, or to name simple and complex types in schema > definitions. Equally, XPath functions should not be declared using > QNames. > > ...I could go on. :) > > So for backwards-compatibility reasons, I think it is a good thing if > documents don't need to be changed. > > Regards, > > Mark > > > Mark Birbeck > CEO > x-port.net Ltd. > > e: Mark.Birbeck@x-port.net > t: +44 (0) 20 7689 9232 > w: http://www.formsPlayer.com/ > b: http://internet-apps.blogspot.com/ > > Download our XForms processor from > http://www.formsPlayer.com/ > -- -harry Harry Halpin, University of Edinburgh http://www.ibiblio.org/hhalpin 6B522426
Received on Friday, 9 June 2006 14:35:55 UTC