W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > May 2008

Re: ISSUE-120: Ambiguous Situation with nested @rel where inner @rel is neither CURIE nor link type

From: Shane McCarron <shane@aptest.com>
Date: Fri, 09 May 2008 09:42:36 -0500
Message-ID: <482462DC.4010408@aptest.com>
To: Ivan Herman <ivan@w3.org>
CC: public-rdf-in-xhtml-tf@w3.org

Ivan,

I apologize if I was too vague before...  Ben and I are aware of those 
clauses and (I think) agree that is what they say.  However, step 10 of 
the processing rules in the current editors draft indicates that any 
incomplete triples are completed BEFORE the child elements are processed 
by recursing.  So, in the example we are contemplating:

> <div about="" rel="dc:creator">
>     <img rel="myfoobarrel" href="ben.jpg" />
> </div>
The surrounding div has an incomplete triple.  That means it should dump 
it, then process the child.  The @rel in the img element has no valid 
CURIEs, so it sets no predicates.  As a result, The child has NO 
triples.... so it should do nothing.  I am pretty sure that this is 
actually what Mark intended. 

The reason I feel this is ambiguous is because 1) you misinterpreted it, 
so others might too; and 2) I was unclear on the definition of the 
phrase "valid @rel or @rev URI".  This is used in a couple of places, 
and I know what it means...  actually if there were just a link back 
from the processing rules where the phrase is used to the definition, 
that would help a lot. 

So, to sum up...  I now believe we do NOT need to change the processing 
rules.  However, I believe your interpretation is wrong and if there is 
some way we can easily, editorially tighten the document so your 
interpretation is harder for people to make, that would be good.

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Friday, 9 May 2008 15:19:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 9 May 2008 15:19:48 GMT