Re: Updated: issue qnameAsId-18

/ Brian McBride <bwm@hplb.hpl.hp.com> was heard to say:
| At 10:32 05/06/2002 -0700, Roy T. Fielding wrote:
[...]
|>  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?

I think that's what Roy meant. It's certainly a problem. I think
that's a really bad idea. If RDF users want to be able to do this, and
I can imagine they might, I think the TAG finding would only be
satisfied if you added a new rdf:typeq attribute. (Actually, I think
I'd make rdf:type the xs:QName attribute and I'd add rdf:uritype, but
I don't have much legacy).

In short, 

| 1) Can you confirm that the RDF practise of using qnames to represent
| URI REF's is consistent with this finding.  If so, you might like to
| mention this in section 2.

In what context?

| 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.

No.

| 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.

Yes, it would be possible to do this in an application, but I don't
think it would be good architecture. For one thing, basing your decision on
whether or not the prefix is defined strikes me as a really bad choice.
Is this a URI or a QName?

   <rdf:Description rdf:type="http:errorcode">

|>   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.

No, but I think it indicates some additional cleanup is required.

I think I'll add a new recommendation:

<item><p>Specifications should not introduce union types that include
<code>xs:QName</code> as a possible component.</p>
</item>

That effectively rules out your case. Either the rdf:type attribute is
xs:string, in which case rule 1 applies, or it is a union type of xs:anyURI
and xs:Qname and now the new rule applies.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM   | Necessity may be the mother of invention, but
XML Standards Engineer | Yankees invent because it's cold outside and
XML Technology Center  | we're cheap.
Sun Microsystems, Inc. |

Received on Wednesday, 5 June 2002 16:04:49 UTC