Re: Updated: issue qnameAsId-18

On 2002-06-05 20:32, "ext Roy T. Fielding" <fielding@apache.org> 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.  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), there is also the extensibility of URI schemes that
> must be considered.  Therefore, a qname must not be allowed anywhere
> that a normal URI is expected.
> 
> ....Roy

I agree that there would be problems if the same attribute could
take either qname or URI. What is the following value, qname
or URI: "foo:bar". It could be both. The lexical properties do
not say for sure which.

But I am very much in favor of allowing the addition of an
attribute which explicitly takes qname values. This would
result in a choice between rdf:ID, rdf:about, and e.g.
rdf:name (or rdf:aboutName... the name of the attribute itself
is secondary).

So, if Brian's question were rephrased to ask if the addition of
an attribute which allowed only qname values would be consistent with the
findings, what would the response be?

Cheers,

Patrick


--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Thursday, 6 June 2002 08:34:08 UTC