W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > February 2008

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

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 18 Feb 2008 17:40:40 -0500
Message-ID: <47BA0968.1030406@digitalbazaar.com>
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:


> 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.


-- manu

Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: RDFa Basics in 8 minutes (video)
Received on Monday, 18 February 2008 22:40:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:55 UTC