Re: Responses to 2nd round of comments on RDFa Syntax by Diego

Hi Manu. Sorry for taking a while to reply, I've been double-checking  
the new rules.

I'm happy with the changes made in response to my two 2nd round  
comments. In particular, the text added in response to the second one  
is very welcome!

However, I've just discovered two new potential issues, so I'm afraid  
I have to raise two new comments:

1) Consider the following markup:

<div about="#Chema">
    <ul rel="foaf:knows">
       <li about="#Diego">...</li>
    </ul>
</div>

I think the code above produces the following triple:

<#Chema> foaf:knows [_:a]

while the expected outcome should probably be the following:

<#Chema> foaf:knows <#Diego>

I think the problem lives in the wording of the final part of Rule 5.  
When the [current element] is the <ul> element, Rule 5 is fired. The  
last branch of the fall-through cases for [current object resource]  
within this rule creates a new bnode for this variable. Immediately,  
Rule 7 creates the triple. Note that Rule 8 is never fired (because  
[current object resource] is a bnode, not null), and therefore, no  
incomplete triple is ever generated.

I admit that I may be wrong, because I've traced the execution by  
hand, so I would appreciate if someone could repeat the trace to  
confirm the issue.

2) I think the list of incomplete triples is not properly propagated  
down the tree. Consider the following markup:

<div about="#Chema">
    <ul rel="foaf:knows">
       <li>
          <span about="#Diego">...</span>
       </li>
    </ul>
</div>

When the processing descends to the <li> element, the [evaluation  
context] should contain an incomplete triple (#Chema, foaf:knows, ??).  
The [local list of incomplete triples] is then initialized to null by  
Rule 1. No other rule is fired for the <li> element, except for the  
recursive rule (Rule 10). At this point, a new [evaluation context] is  
created for the child <span>, and the [list of incomplete rules] of  
this new context is initialized to the value of [local list of  
incomplete triples], which is null. Therefore, when the third  
component of the triple is discovered (while processing the <span>),  
the first two components are not available anymore, and the triple  
cannot be completed.

As before, this may be an error in my trace and not an actual error in  
the rules, so please repeat the experiment before making any changes  
to the document.

Best regards,

Diego.

El 18/02/2008, a las 4:39, Manu Sporny escribió:

> Diego had sent in two official comments on the Last Call ready draft
> earlier today. The comments were about this document:
>
> http://www.w3.org/MarkUp/Drafts/ED-rdfa-syntax-20080217/
>
> I am making a public note of it by posting those comments to the RDFa
> mailing list.
>
> Mark has made changes to address those comments. Responses with  
> pointers
> to the diff can be found below:
>
>> * Having two variables with the same name and different scope may
>> lead to confusions. This mainly applies to the "list of incomplete
>> triples", which exist both in the context and as a local variable.
>> For instance, can you tell which one is referred (twice) in Rule 8?
>> ((Btw, in the second box of that rule, I think "[incomplete triples]"
>> should be replaced with "[LIST OF incomplete triples]")).
>> My suggestion
>> is to rename the local variable to "list of NEW incomplete triples"
>> in order to remove any source of ambiguity.
>
> The distinction is now made between the [local list of incomplete
> triples] and the [list of incomplete triples] that come from the
> [evaluation context].
>
> See Steps #8 and #10:
>
> http://www.w3.org/MarkUp/Drafts/ED-rdfa-syntax-20080217/rdfa-syntax-diff.html#sec_5.5 
> .
>
>> * Rule 11 contains the clause "If the process of recursion returns
>> 'true'...", but this value not computed until Rule 12. Therefore,
>> I wonder if that the actual meaning would be better captured by
>> this phrase: "If there are child elements of the current element,
>> and the process of recursion returns 'true' for ANY of the child
>> elements...". Note that in this case, Rule 12 may have to be modified
>> accordingly, in particular this fragment: "or a value of 'true' was
>> returned from the recursion step". In other words: you should make
>> clear how the individual return values from the child elements are
>> composed after Rule 10.
>
> The prose has been updated to address the concerns that you list  
> above.
> The text is very detailed now, explaining the purpose of the recursion
> return value and how it is used:
>
> See Step #10, #11, and #12:
>
> http://www.w3.org/MarkUp/Drafts/ED-rdfa-syntax-20080217/rdfa-syntax-diff.html#sec_5.5 
> .
>
> -- manu
>
> -- 
> Manu Sporny
> President/CEO - Digital Bazaar, Inc.
> blog: RDFa Basics in 8 minutes (video)
> http://blog.digitalbazaar.com/2008/01/07/rdfa-basics/

Received on Monday, 18 February 2008 20:13:43 UTC