- From: Brian McBride <bwm@hplb.hpl.hp.com>
- Date: Wed, 05 Jun 2002 19:20:52 +0100
- To: "Roy T. Fielding" <fielding@apache.org>
- Cc: Norman Walsh <Norman.Walsh@sun.com>, www-tag@w3.org
At 10:32 05/06/2002 -0700, Roy T. Fielding wrote: >>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. It is common practice in RDF land to write rdfs:Class instead of http://www.w3.org/2000/01/rdf-schema#Class >Aside from the issue of mixing parser context >(the URI parser knows nothing about qnames and the XML parser can't >reliably peek into every element attribute looking for things that >might be qnames), Hmmm, you seem to have a specific processing model in mind. Its possible to build a processing system that does this, I assert without having built one. > there is also the extensibility of URI schemes that >must be considered. Are you referring to the problem that faced with: <rdf:Description rdf:type="rdfs:Class"> how does one tell if the "rdfs:Class" is a URI or a qname? RDFCore has not considered the details of how this might be done, and when it does it might well agree with you that the solutions are ugly and unacceptable. However, it is possible to have a rule to decide, e.g. if it looks like a qname, and the prefix matches a defined namespace prefix, then it is a qname, otherwise its not. > Therefore, a qname must not be allowed anywhere >that a normal URI is expected. Sorry, I didn't get the logic of that "therefore". My question was related to the specific proposed TAG finding on this question. Brian
Received on Wednesday, 5 June 2002 14:30:46 UTC