RE: QName URI Scheme Re-Visited, Revised, and Revealing (was RE : De dicated, Standardized URI Scheme for QNames?)

> The bottom line is: in general, QNames don't work like URIs;
> their scope is not the global internet scope; their scope depends
> on how you use them. XML Schemas allow the meaning
> of a QName to depend on the parent elements, for
> example.

Thanks for this clarification. So in fact, QNames alone are not
universal identifiers -- rather QNames combined with partition
information provide universal identity but not in a single
lexical form. Hmmmm...

So something like the revised qn URI scheme which explicitly
includes partition information is needed to achieve QName
based universal identifiers. Right?

> But if you're looking for a single mapping from QNames
> to URIs, there isn't one that's consistent with
> all of XSLT, RDF, and XML Schemas. Perhaps it's worth
> taking the time to design one that does work, but I'm
> pretty sure you'll have to do some substantial
> redesign of at least one of those three, and I'm
> not sure that's worthwhile.

What a pity. 

> [...]
> > Two questions can IMO direct this issue one way or another:
> > 
> > 1. Can a QName used in one partition represent semantics that is not
> > equivalent
> > to the semantics attributed to the same QName in another partition?
> 
> In the general case, where a "partition" can be any sort
> of structure, yes, the same QName can denote different
> things for any sort of reason at the whim of the designer
> of the XML sublanguage.
> 
> > I.e. can an element <foo:bar> a global attribute <... 
> foo:bar="..."> and
> > a per-element attribute <... bar="..."> all mean different things?
> 
> Yes.

Agreed.
 
> > 2. And if so, is RDF required to maintain that distinction?
> 
> No.

I'm not quite convinced of that -- but being the realist that I am, I
appreciate that the current RDF spec takes this view and it's highly
unlikely that that will be changed.

As I mentioned (I think reasonably clearly) early on in my proposal
regarding the qn URI, I did not expect it to be a viable option, because
of the need for backwards compatibility in future versions of the RDF
spec, but that it was simply "food for discussion" -- which it certainly has
turned out to be. I think that discussion has been fruitful -- if only
to emphasise that there are non-trivial issues relating to RDFs
mapping from QNames to URIs that are not (apparently) sufficiently clarified
and detailed in the official documentation and which should be clearly
understood by anyone selecting namespace URIs for use with RDF.

The issue of QName->URI->QName inconsistency essentially means that one
can only ever utilize non-RDF XML operations based on QName-defined
vocabularies before such data enters RDF-space; as afterwards, such
QName vocabularies are "undefined", since RDF does not know about them
via maintaining the namespace/name distinction.

Even if adoption of an explicit QName URI scheme is not viable (for
backwards compatibility reasons) in place of the current mapping, that
does not mean that there are not still significant issues with the present
mapping function. Maybe they can never be addressed in the standard
due to the same backwards compatibility constraints that serve for
rejection of a QName URI, but at the very least, they should be documented
clearly in revised versions of the spec so that users of RDF are made aware 
of those issues and understand the potential impact on their use of RDF.

Regards,

Patrick

--
Patrick Stickler                      Phone:  +358 3 356 0209
Senior Research Scientist             Mobile: +358 50 483 9453
Software Technology Laboratory        Fax:    +358 7180 35409
Nokia Research Center                 Video:  +358 3 356 0209 / 4227
Visiokatu 1, 33720 Tampere, Finland   Email:  patrick.stickler@nokia.com

Received on Friday, 24 August 2001 01:25:03 UTC