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

Let us not fight on words whether it is ambiguous or not...:-)  I just 
try to exactly pin-point where Ben's described effect comes from.

The current processing step says, in step #4 of the processing steps 
(both in the LC and the editor's document):

[[[
[...] if the [current element] contains no valid @rel or @rev URI, 
obtained according to the section on CURIE and URI Processing, then the 
next step is to establish a value for [...]
]]]

which is what applies in our case and leads to, well, what it leads to. 
So the core question is what constitutes a valid @rel/@rev value. That 
is described in sections 5.4.3 and 5.4.4. In my understanding  (eg, 
paragraph just before 5.4.4. and paragraph 5.4.4. itself) those chapter 
specify what valid @rel/@rev values are, namely URI-s drawn from full 
blown curies with a prefix and a reference, or the predefined @rel 
values. The example given by Ben is not a valid XHTML value, ie, the 
@rel is not a valid URI, ie, the processing step quoted above does not 
apply.

This may not have been the intention, but this is certainly properly 
defined.

Changing that would mean changing the processing step description or 
redefining what a valid @rel/@rev value is. My fear is that the 
processing step description is like those 'castles' we used to build 
from cards when we were kids: touch one, the building can collapse:-) We 
also spent quite a lot of time on the valid @rel/@rev values...

Ivan

Shane McCarron wrote:
> 
> 
> Ivan Herman wrote:
>> Hi Ben,
>>
>> to be ruthlessly precise, the situation is not ambiguous; as you say, 
>> the spec leads to
>>
>> <> dc:creator <ben.jpg>.
>>
>> (this is also what my implementation does:-)
> I disagree.  I think the spec is ambiguous.  If we WANT the spec to lead 
> to that, then I think it would be relatively easy to say something like 
> "If there are no value values for a given attribute, the processor 
> should act as if the attribute was not specified at all."  However, I do 
> not believe that was Mark's intent.  His intent was to be able to STOP 
> the cascade by putting in a rel="".  If we add a restriction like the 
> one above, then such a thing would not work.  We could, of course, add a 
> further qualification when an empty attribute value is encountered.  We 
> already do that for @about, so we could extend it.
> 
> I agree with you that making any changes at this late date is a really 
> bad idea.  But I think that the current spec is accidentally ambiguous.
> 
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf