[RDFa] review of the syntax editor's draft

El jue, 27-09-2007 a las 12:15 -0700, Ben Adida escribió:
> We noticed two small bugs in the RDFa syntax document editors' draft.
> Since they may lead to misunderstandings if you're looking at the
> details, we immediately pushed out a new draft:
> 
> http://www.w3.org/MarkUp/2007/ED-rdfa-syntax-20070927


Hi all,

Find below my review of the "RDFa in XHTML: Syntax" Editor's Draft.
I apologize for any comment that might come from my
misunderstandings and not from actual issues in the draft.
I've skipped some trivial issues, such as broken or missing
references (DBpedia, for instance). I have little knowledge of DTD's,
so I couldn't properly review Appendix B.

I'd be glad to discuss these items in the Amsterdam f2f, or through the
mailing lists.

Best regards,

*********************

- The <title> and the <h1> of the draft doesn't match. Which one is
the correct title of the document?

[[[
<title>RDFa in XHTML: Syntax and Processing</title>
...
<h1><a id="title" name="title"> RDFa in XHTML: Syntax</a></h1>
]]]

*********************

- In Section 3.9, third paragraph:

[[[
predicates are represented using one of @property, @instanceof, @rel,
or @rev
]]]

IMO, @instanceof does not "represent" a predicate in the same sense as
@property or @rel. While the content of @property and @rel are URIs
(CURIEs) of RDF properties, the content of @instanceof is a class URI.
The actual predicate (rdf:type) is implied by the atribute.

My proposal is to remove "@instanceof" from the list.

Note that, two paragraphs before Section 6.1, we find this:

[[[
The attributes for setting a predicate are @rel, @rev and @property
]]]

which I think is correct, and apparently conflicts with the previous
quote.

*********************

- In Section 5.3 ("Processing"), references are made to two flags
("recurse" and "chaining") which are undefined. It is not clear if
they're part of the "evaluation context" (Section 5.2) or not. I think
a note should be added to point explicitly they aren't part of the
"evaluation context" (this is important because we don't want them
pushed into the stack in rule 6). A similar remark can be done for
the variables "current object resource" and "current object literal"
which appear for the first time in the 2nd rule.

*********************

- In Section 6.2.2.2 ("Using @href"), the text following the first
blue box is actually about the usage of "@rel" and "@rev", not about
"@href". As the former can be used with other attributes besides @href
(such as @resource, described in the preceding section), I think this
text shouldn't be hidden in the Section concerning @href. Please
consider moving these paragraphs about @rel/@rev to a section of
their own.

*********************

- Section 6.2.2.4 ("Using a blank node to set the object") is a bit
awkward to understand. Consider the first phrase:

[[[
When a triple predicate has been expressed using @rel, and no @href,
@src, or @resource exists on the same [RDFa element], then the CURIE
represented by this element is used as the object.
]]]

What is "the CURIE represented by this element"? How is it computed?


*********************

- In the example in Section 9.2.1, the @property attribute is
highlighted, while I think it should be the @about attribute the
one which is highlighted.

*********************

- In Section 9.2.4 ("The instanceof attribute"):

[[[
This attribute indicates the rdf:type of the associated triple(s).
]]]

I would rather say "the associated resource" or "the associated
subject" instead of "the associated triple", because RDF triples
have no "rdf:type" (unless we reify them, of course).

*********************

- At the bottom of Section 9.2.5 there are two examples that are
supposed to be equivalent (i.e.: they should yield the same RDF
triplets). Are RDFa user agents expected to process both
syntaxes?

*********************

- In Section C.2 (Related Activities), the name of the SWD WG is
not correct:

[[[
Semantic Web Best Deployment Working Group
]]]

*********************

- Regarding the processing model, in the first paragraph of
Section 5.1 ("Overview"):

[[[
Parsing a document for RDFa triples is carried out by starting at the
root element of the document, and visiting each of its child elements
in turn, applying processing rules. Processing is recursive in that
for each child element the processor also visits each of its child
elements, and applies the same processing rules.
]]]

Later, in Section 5.3:

[[[
Processing then begins with the root element, and all nodes in the
tree are processed according to the following rules, depth-first.
]]]

>From the order of the rules, it follows that each node in the
tree is processed _before_ any of its children. IIRC, the precise
term for this is "pre-order".

Moreover, the rules can be applied only to nodes of type _element_.
Other kinds of DOM nodes, such as text nodes, attributes or
comments don't participate directly in the rules. Therefore, I
suggest to replace the term "node(s)" by the more precise
"element(s)" (e.g.: in the second quote above, also in rules 1 and 6,
and at the end of section 6.2.1.3). Note that, if we don't explicitly
restrict the rules to "elements", we can't safely use expressions
such as "current element" and "current element identifier".

*********************

- The 6th processing rule is not clear enough regarding how
the evaluation context is transmitted to the child elements:

[[[
If the [recurse] flag is true, the [current evaluation context] is
pushed onto a stack, and all nodes that are children of the [current
element] are processed using the rules described here. Once all of
the children have been processed then the [current evaluation context]
is popped back off the stack.
]]]

Does this mean that _all_ the children share _the same_ evaluation
context? IMO, this would be an error. Consider the following example:

<div about="#a">
  <span about="#b" property="foaf:name">Albert</span>
  <span property="foaf:name">Stephen</span>
</div>

Let's trace the rules: after the outer <div> has been processed, the
current evaluation context contains current_resource="#a". By the
6th rule, we now push the current evaluation context into the
stack, and descend to the child elements. Nothing is said about
how to initialize the current evaluation context for the
children, so we assume that it's the same context as the one that we
just pushed into the stack. Processing the first <span> changes the
current_resource to "#b". As the first <span> has no child elements,
there is nothing to push or pop from the stack. We still continue
using the same evaluation context. Then the second <span>
is processed, but the current_resource is no longer "#a" (as we could
expect), but "#b". A wrong triplet (#b,foaf:surname,Einstein) is
generated. Finally, the old evaluation context is popped back off the
stack.

I propose two alternative fixes:

a) To remove the stack, as it's just an implementation detail. The
6th rule could be rewritten as follows:

"If the [recurse] flag is true, all nodes that are children of the
[current element] are processed using the rules described here. Each
one of the children receives an identical copy of the [current
evaluation context]."

b) To keep the stack, but add a new rule to be executed before all
the other ones (the 0th rule):

"The [current evaluation context] is copied from the top of the
stack (but not popped!). If the stack is empty, an initial
[evaluation context] is generated as described in Section 5.2."

*********************

- Which is the value of the [current object literal] when the
current element has child nodes that are neither elements nor
text nodes (for instance, comments)?:

<span property="foaf:name">
  <!-- this is the name of the person -->
  Albert
</span>

Is it a rdf:XMLLiteral or a xsd:string?

*********************

-- 
Diego Berrueta
R&D Department  -  CTIC Foundation
E-mail: diego.berrueta@fundacionctic.org
Phone: +34 984 29 12 12
Parque Científico Tecnológico Gijón-Asturias-Spain
www.fundacionctic.org