- From: Bill de hÓra <dehora@eircom.net>
- Date: Wed, 5 Jun 2002 21:00:21 +0100
- To: <www-tag@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] > 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 cite. Bill de hÓra -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPP5t0+aWiFwg2CH4EQLbkACeOpqXPL7XHOGqYj50+uOI9mQR2fwAn33r s61ksU4LI6hrLR4BAJDLXFwm =hKVo -----END PGP SIGNATURE-----
Received on Wednesday, 5 June 2002 16:02:53 UTC