- From: Shane McCarron <shane@aptest.com>
- Date: Mon, 18 Feb 2008 14:44:15 -0600
- To: Mark Birbeck <mark.birbeck@x-port.net>
- CC: Diego Berrueta Muñoz <diego.berrueta@fundacionctic.org>, Manu Sporny <msporny@digitalbazaar.com>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>
I am sure that Manu will send out something more formal, but as Mark implied that updated draft is available at http://www.w3.org/MarkUp/2008/ED-rdfa-syntax-20080218/ - note that this is still diff marked against the 0125 draft so you can see what all the changes are that resulted from your (astute) comments. Thanks again! Mark Birbeck wrote: > Hi Diego, > > Very well spotted on both counts. You are exactly right on both > issues. You'll be pleased to hear, though, that Ivan spotted both of > these problems earlier today, and so I believe I have already > addressed your issues. Shane is about to publish another draft for you > to check that you are happy with those changes. > > Thanks again for your thorough examination of the rules--I think it is > making for an increasingly watertight definition. > > Regards, > > Mark > > On 18/02/2008, Diego Berrueta Muñoz <diego.berrueta@fundacionctic.org> wrote: > >> 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/ >>> >> >> > > > -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com
Received on Monday, 18 February 2008 20:44:31 UTC