- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Mon, 18 Feb 2008 17:40:40 -0500
- To: Diego Berrueta Muņoz <diego.berrueta@fundacionctic.org>
- CC: RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>
Diego Berrueta Muņoz wrote: > Hi Manu. Sorry for taking a while to reply, I've been double-checking > the new rules. No problem, all of us appreciate that fact that you keep reviewing and re-reviewing the changes. > 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! Glad you like the changes so far :) > 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. You're quite correct. There was a bug in the processing rules that caused the 8th rule to not fire. This has been corrected in the latest Last Call-ready draft by fixing Step #5. Note that the rule at the end of Step #5 that caused [current object resource] to be set to a non-null value has been removed. By removing this step, we ensure that the list of incomplete triples can be created correctly. Please note the changes in Step #5: http://www.w3.org/MarkUp/2008/ED-rdfa-syntax-20080218/rdfa-syntax-diff.html#sec_5.5. > 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. Correct again. This issue has been addressed by creating a [skip element flag]. If the [skip element flag] is set to 'true', then the [list of incomplete triples] is propagated down the tree when processing (note that xml:lang and xmlns are still processed as well). Please note the changes in Step #1, Step #4, Step #11, and Step #12. http://www.w3.org/MarkUp/2008/ED-rdfa-syntax-20080218/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 22:40:54 UTC