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

Shane McCarron wrote:
>>
>> I tried to look at the possible changes if we want to achieve what Ben 
>> asks for. Here is one way, maybe:
>>
>> #4 comes into effect if _no_ @rel/@rev are present, regardless of 
>> whether the value is valid or not
>>
>> There is a #4a which comes into effect if @rel/@rev is present but 
>> they contain no valid URI-s; in which case the [new subject] is set to 
>> @about or a new BNode
 >
> I believe this is what Mark intended, and it enables the (edge) case 
> that you can stop chaining by inserting an empty rel, which was 
> something we had discussed at one time.

Yes, that is correct. Which may be a very useful feature indeed...

>>
>> #5 comes into effect otherwise
>>
>> Hm. Is such a change editorial or does it send us back to LC2?
 >
> I think it is certainly editorial.  I am not certain that it makes Ben 
> or Mark happy though.  I personally don't care what the answer is.  I 
> would also be happy with changing text in section 5.4.3 by adding to the 
> end of the conditions "Regardless of the datatype of the attribute, if 
> evaluation of the attribute value for CURIEs and URIs results in no 
> valid URIs, a conforming processor MUST behave as if the element has no 
> specification of the attribute (e.g., as if there is no entry for the 
> attribute in the DOM tree at all)."

But that would not solve the original problem, would it? The issue seems 
to be that the current description of step 4 does not make a difference 
between (a) @rel/@rev not around at all and (b) they are around albeit 
with invalid values. So if the behaviour is as if the DOM tree did not 
have the attribute at all, step 4 would still prevail...

Let us see what Ben and Mark have to say....

Sigh...:-)

Have a nice week-end!

ivan

-- 

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

Received on Friday, 9 May 2008 17:39:17 UTC