Re: Issue #rdf-ns-prefix-confusion

Dave Beckett <dave.beckett@bristol.ac.uk> wrote:

> [Hmm, looking at the timestamp, it was sent 3 minutes into our last
> meeting :-) ]

[Actually, that's because the telecon was the first time my machine had an
Internet connection that day, so all my unsent mail went out.]

>>> 7.  Unprefixed attributes not on The List have no meaning in RDF
>>>    and MUST NOT be used to generate statements.   Processors MUST
>>>    also skip the element containing such attributes and generate no
>>>    statements for the entire XML element and content.
>>> 
>>> This is to explicitly say what is implict in the the BNF - unprefixed
>>> attributes have never been allowed in RDF/XML grammar.  I've gone a
>>> bit further to say what to do when they are seen so that there is
>>> so consistency in handling them.  This means that all namespace
>>> element/attribute prefixing is covered.
>> 
>> I do not think that this extra step is necessary. Take the innocent mistake:
>> 
>> <rdf:RDF xmlns:rdf="..." xmlns="..."
>> <rdf:Description title="Issues" author="Dave Beckett">
>>   <type rdf:resource="http://example.org/#image" />
>> </rdf:Description>
>> </rdf:RDF>
> 
> This is too vague - please fill in the namespace URIs; are they both
> to the RDF namespace URI or not?

Sorry for not being clear, I can never remember the RDF namespace
(especially offline) and hate typing it. (Hmm...) The idea was that the
default namespace was Dublin Core (oops, author should have been creator --
sorry). 

> I also don't want RDF/N3 used
> to explain RDF/XML in this forum - it confuses issues and moves the
> discussion to what RDF/N3 means rather than RDF/XML.

I'm using RDF/N3 to display triples, since it's a language that's easy to
understand and has a parser. I'm trying not to use any of the advanced and
unclear features of N3 like reification.

> Either way, considering 'title' and 'author' - some parsers will
> assume they are rdf: concepts due to implementing XML namespaces
> wrong (the rdf: on rdf:Description does not pass to the attributes)
> and hence could skip the element as it contains unknown RDF
> attributes.  Other processors might do all sorts of strange things
> creating bare 'title' properties or maybe documentURI#title
> properties.
> 
> By writing a paragraph like the above, all this is precisely clear -
> unprefixed attributes continue to not be allowed.

I understand this -- what I don't see is why we can't state that they MUST
be ignored, rather than destroying the whole chunk of RDF that contains
them.

>> Also, I too agree with Dan Connolly and would like to see the MUST changed
>> to a MAY, so that processors may accept the incorrect version of the
>> language for backwards compatibility, but it is not an accepted portion of
>> the language.
> 
> We discussed that subsequently during the meeting and agreed to make
> the stronger deprecation point - deprecated now (SHOULD NOT) and tell
> the developers so that they know it will be removed and forbidden
> (MUST NOT) at next REC which is probably a year away.

I do not see what this refers to in your proposal. What I was talking about
was exactly the opposite:

<q 
cite="http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001May/0087.html">

3.  On input, processors MUST accept unprefixed attributes from The
    List on any elements.  These attributes must be processed
    as if they were written with a prefix as defined in #2.

</q>

This MUST should be changed to a MAY, so that processors need not accept
documents with unprefixed attributes. RDF itself should remain strong,
continuing to state that "A namespace prefix MUST be used for these
attributes...".

> In summary, based on what existing tools do and for consistency, item
> 7 remains a good answer.

I don't see that from your message.

-- 
Aaron Swartz <me@aaronsw.com>|               RSS Info
  <http://www.aaronsw.com>   |   <http://www.blogspace.com/rss/>
AIM: JediOfPi | ICQ: 33158237| news and information on the RSS format

Received on Wednesday, 23 May 2001 12:05:09 UTC