- From: Jonathan Borden <jonathan@openhealth.org>
- Date: Wed, 5 Jun 2002 13:59:20 -0400
- To: "Dan Connolly" <connolly@w3.org>, "Brian McBride" <bwm@hplb.hpl.hp.com>
- Cc: "Norman Walsh" <Norman.Walsh@sun.com>, <www-tag@w3.org>
Dan Connolly wrote: > > On Wed, 2002-06-05 at 10:10, Brian McBride 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. > > > I don't expect so. > > Rather, RDF would have one resource="..uri ref here..." > attribute, and one rdf:resourceQ="...qname here..." attribute. I wholeheartedly agree with the idea of having distinct resourceQ, aboutQ attributes. Regarding the qnameAsId issue, which is now water over the dam as XSLT/XPath has become widespread and successful, I would prefer incorporating language acknowledging XPath's use of qnames, which goes beyond xs:Qname, e.g. "Use of QNames within attribute content may be signalled by a regular expression defined type such as [ex:QNameTokens]. When used in this fashion, an implicit or explicit namespace context must exist within which namespace prefixes are bound to namespace URIs. " Ideally the regular expression which is used to define a QName containing string would have been defined by XML Schema as a builtin type, but this issue wasn't apparently apparent at the time :-/ Jonathan
Received on Wednesday, 5 June 2002 14:04:10 UTC