RE: Updated: issue qnameAsId-18

Hash: SHA1

> -----Original Message-----
> From: []
> On Behalf Of Roy T. Fielding
> > 2) RDFCore has an outstanding issue to allow qnames as
> > attribute values
> > as a shorthand for a URI REF.  This would mean that RDF would
> > have  attributes which allowed either a URI or a qname in the 
> same attribute
> > value.  Would RDF be consistent with this finding if it
> were to go ahead
> > and allow that.
> That is a terrible idea.  Aside from the issue of mixing
> parser context (the URI parser knows nothing about qnames and 

RDF doesn't have a processing model, thus such a parser context is
an implementation detail and can't be assumed to be the case.

> the XML parser can't reliably peek into every element
> attribute looking for things that might be qnames), 

Again, that's making assumptions about implementations. If an XML
parser can do it for elements and attributes, what's distinct about
attribute values? Note that XML Schema uses qnames in attribute
values, so the W3C has already sanctioned this. In any case the
burden if there is any, is likely to lie with whomever receives the
parser tokens/events (ie a SAX handler).  Plus it doesn't help that
XML namespaces doesn't say either way and doesn't disallow  or
discourage using namespace prefixes that happen to be registered
URI schemes, so we can assume it's allowed and some joker is going
to do this in RDF XML.

> there is
> also the extensibility of URI schemes that must be 
> considered.  

If a namespace prefix happens to be http it will get expanded. XML
Schema might have issues if someone ever registers the xsd: URI
scheme, and indeed weird things might happen in the processing
chain soon enough if people use urn: et al as a namespace prefix.

> Therefore, a qname must not be allowed anywhere 
> that a normal URI is expected.

It probably is a bad idea (Dan Connolly's suggestion seems far
saner), but respectfully, this does not follow from the grounds you

Bill de hÓra

Version: PGP 7.0.4


Received on Wednesday, 5 June 2002 16:02:53 UTC