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/