Re: [RDFa] review of the syntax editor's draft

I have fixed many of these, and annotated the rest with "LEAVING FOR 
MARK".  Mark, let's sync on what we need to do to get those issues 
settled or recorded as formal issues.

Diego Berrueta Munoz wrote:
>
> *********************
>
> - 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>
> ]]]
>
FIXED
>
> *********************
>
> - 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.
>
FIXED
>
>
> *********************
>
> - 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.
>
LEAVING FOR MARK
>
>
> *********************
>
> - 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.
>
LEAVING FOR MARK
>
>
> *********************
>
> - 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?
>
LEAVING FOR MARK
>
>
>
> *********************
>
> - 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.
>
FIXED
>
>
> *********************
>
> - 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).
>
FIXED
>
>
> *********************
>
> - 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?
>
No, this was vestigial text from XHTML2.  It has been removed.

FIXED
>
>
> *********************
>
> - In Section C.2 (Related Activities), the name of the SWD WG is
> not correct:
>
> [[[
> Semantic Web Best Deployment Working Group
> ]]]
>
FIXED
>
>
> *********************
>
> - 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".
>
LEAVING FOR MARK
>
>
> *********************
>
> - 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."
>
LEAVING FOR MARK
>
>
> *********************
>
> - 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?
>
LEAVING FOR MARK

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com