W3C home > Mailing lists > Public > www-tag@w3.org > June 2002

Re: Updated: issue qnameAsId-18

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Wed, 05 Jun 2002 19:20:52 +0100
Message-Id: <5.1.0.14.0.20020605190822.0269ea90@15.144.25.13>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:52 UTC