QName URI mapping

Graham Klyne wrote:

"
The forward transformation from QName -> URI is clear and unambiguous per
the original RDF specification.  It is the reverse transformation that is
problematic.
"

To be clear, while I would prefer that a bidirectional mapping be possible,
just as I would _greatly_ prefer that the RDF model <-> XML mapping be
bidirectional and roundtripable, there are issues with the simple forward
transformation.

In particular the model XML Schema uses for use of a QName as a type
specifier is that the namespace name/URI is like the 'base URI' of the
schema (quotes because it is not quite that simple but nonetheless) and that
the localname is used as a locator for the type declaration within the
schema module. In URI terms, XML Schema thus treats the localname LIKE a
fragment identifier. It is not exactly a fragment identifier for several
reasons, namely that no fragment identifer syntax is (yet)defined for
application/xml and particularly because the localname maps to the XML
Schema "name" attribute which is not ot type ID.

For this reason I have issues with the forward QName -> URI mapping if this
is a simple string concatenation.

For the vast majority of RDF namespaces, perhaps all of the deployed RDF
namespaces, simple concatenation is exactly the same as treating the
localname as a fragment identifier (it comes after the '#') but for XML
namespaces in general this is not the case. RDF does not require its
namespaces to end in '#' hence one of the reasons for the incompatibility.

I cannot say for sure that this incompatibility is entirely the 'fault' of
RDF (although the mapping is perhaps too simplistic), rather a breakdown in
communications and coordination between the RDF WG and other WGs more
intimately involved in XML activities. It is not important to me where this
incompatibility gets fixed, and since it is a basic architectural issue I
agree with Brian and Tim Bray that the TAG ought be involved in this issue.
For that reason alone, I would prefer that the issue not be closed for the
moment.

Jonathan

Received on Wednesday, 23 January 2002 00:07:05 UTC