- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Tue, 8 Nov 2005 22:04:00 -0000
- To: "'Norman Walsh'" <Norman.Walsh@Sun.COM>
- Cc: <public-rdf-in-xhtml-tf@w3.org>
Hi Norman, First I have to apologise; I wouldn't normally reply with such pedantry as follows, but since one of my main arguments in favour of CURIEs is that we need a way to abbreviate URIs in a manner that has *already* become established practice via QNames, then I feel I have to take issue with your statements about N3. I'll then go on to the main part of the argument, which is whether there could be a misunderstanding if CURIEs were to 'look like' QNames. I wrote: > | (This *would be* N3, except it isn't, because N3 is another > example of > | a language that mandates QNames...which sort of makes the > point that > | I've been trying to argue; when a non-XML language like N3 > restricts > | the way that 'abbreviated URIs' are formed, to that used in > | XML+Namespaces element and attribute name formation, you know > | something has gone wrong!) You replied: > That argument doesn't hold for N3. N3 is a serialization > format for RDF. Yes, that's right...for RDF, not RDF/XML. There is no reason to import QNames into N3 since it has nothing to do with XML (just like RDF has nothing to do with XML). > RDF has an XML syntax for which N3 is attempting to be an alternate > serialization. No. N3 and RDF/XML are *both* alternate serialisations (to each other) for RDF. > It seems > entirely reasonable in that circumstance that N3 should have > more restrictions than are actually, grammatically necessary in N3. I can't see why. N3 only represents RDF--it has no relationship to XML whatsoever. You could get rid of RDF/XML tomorrow, and both RDF (the underlying information) and N3 (one possible serialisation of it) would be untouched. That's the pedantry out of the way...so, to summarise, N3 *already* shows that there is a glaringly obvious need for a way to abbreviate URIs. But since there was no readily available mechanism to do this, N3 (in common with others) opted to use QNames. This is particularly bad in general, since there is no relationship between the URI expressed and an XML+Namespaces element or attribute name (as indicated in the TAG report). But it is also particularly bad in the specific context of N3, since this syntax doesn't even have anything to do with XML. I feel I have established in many ways now, in many emails, both the need and the precedent, so hopefully the question now becomes, where do we go from here? To recap the argument, my proposal uses the same *mechanism* as QNames, but produces a wider range of URIs. Your argument is that this is wrong since a CURIE and a QName could get mixed up, to which I would say: * QNames are already being used (inappropriately) as URI abbreviations, without confusion. This is because when the context is a 'real' QName (an element or attribute name with a 'namespace part') the local name and namespace part are never actually combined in the way that has become common practice in RDF/XML, XForms, N3, and so on. In other words, whether x:y maps to { http://x#, y } or http://x#y is already given by context; * any situation where a CURIE is valid, a QName (in the *proper* sense) will also be valid, and any situation where a QName *only* is valid, then only CURIEs that conform to a QName will be valid (just in the same way that only numbers that conform to the positive integer pattern match correctly for a positive integer). As I've said before, the horse has already bolted when it comes to the use of QNames to represent URIs. My proposal does not seek to make the problem worse by polluting the *genuine* QName space with relaxed rules for the local-name part; rather it proposes a new way of representing URIs in abbreviated form, using the widely understood *mechanism* popularised by QNames. One way out of this would be to define the *mechanism* (a namespace prefix, followed by a colon, followed by a local part) as some sort of standalone thing. And then to layer onto that, what one does with the bits you end up with after parsing the abbreviation: / x:y | | The mechanism: < | | | \ { http://x#, y } / | \ / | \ QName: { http://x#, y } | \ | \ XPath function: { http://x#, y } \ \ URI: http:x#y The mechanism just converts prefixes and local parts to an 'object'. QNames-proper leave that object intact and make use of it, as do XPath functions, whilst CURIEs would add another processing step and convert that object to a URI. I feel this is *clearer* than current practice, since now 'QNames' really are QNames. 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/ Download our XForms processor from http://www.formsPlayer.com/
Received on Tuesday, 8 November 2005 22:04:30 UTC