Re: Question on namespace confusion (more on Re: New syntax spec )

>>>Rick Jelliffe said:
> Still trying to work through the Schematron schema for RDF, to present
> at XML 2001 in Florida in December. It is starting to be pretty good now.
> I have a question regarding the "namespace confusion" and the test cases.
> I can understand a rule such as 
>  "All the attributes on an element in the RDF namespace must be qualified
>   (and therefore prefixed.)"
> That copes with test files error0001.rdf and error0002.rdf file.
> But the third test case
> <rdf:RDF>
>   <rdf:Description rdf:about="">
>     <eg:property resource=""/>
>  </rdf:Description>
> </rdf:RDF>
> is deemed an error because (I think) it should be 
> <rdf:RDF>
>   <rdf:Description rdf:about="">
>     <eg:property rdf:resource=""/>
>  </rdf:Description>
> </rdf:RDF>

Yes - that is the reason error0003.rdf is an error.

> But this would be an example of RDF telling an element in another
> namespace what local attribute names it is allowed to have!  This
> is of course utterly against the point of partitioning off names
> into namespace, so I must be missing some step.

I was the original owner of that issue and wrote those tests cases;
so I'll answer this.  RDF/XML has been modified to forbid unprefixed
attributes anywhere in the syntax. i.e. local attribute names are
not allowed.  This was done due to widespread confusion about
namespaces and attributes.  Different deployed applications thought
that in
     <eg:property resource=""/>

resource actually was eg:resource, others that it was
(default xmlns namespace):resource, and others recognised it
as the rdf special attribute that it is.

     <eg:property rdf:resource=""/>
is clear.

Other attributes (propAttr) have always required explicit prefixes in
RDF/XML and continue to do so.  RDF/XML has never had a meaning for
(element-)local attribute names.

> According to the refactored spec, the eg:property attribute is admissible as
> a 4.6 propertElt 
>   element([namespace name]=any,
>     [local name]=any,
>     [attributes]=set(idAttr?),
>     [children]=list(character()+))
> Is the test case wrong, or are there unstated co-occurrence constraints
> in the refactored productions?  

Sorry, you've lost me there - an attribute permissible as an element?



Received on Monday, 17 September 2001 09:24:50 UTC