Re: review of current draft of 'RDFa syntax (Jan 25th, 2008)'

Diego,

What follows is a point-by-point reply to your comments on the RDFa
Syntax document sent on January 29th, 2008. It would be greatly
appreciated if you could review the changes and reply to the list
stating your approval of the changes, or any issues you see with the
changes.  The updated draft is available at 
http://www.w3.org/MarkUp/Drafts/ED-rdfa-syntax-20080217/Overview.html

Diego Berrueta wrote:
> Substantial comments:
>
> * Section 5.5, paragraph starting with "Processing begins with...". In
> addition to elements containing one or more RDFa attributes, rules must
> be applied _also_ to elements containing XML namespace declarations and
> xml:lang attributes, even if they don't contain any RDFa attribute.
> Otherwise, if some elements are skipped, rules 2 and 3 may fail to be
> fired. My suggestion here is to simply say that every element should be
> processed.

The language in the document has been clarified.

> * Section 5.5: I can't find any rule to set a value for "parent bnode"
> and "parent object". Rules 4 and 5 peek the value of these variables,
> and Rule 6 clear their value, but it seems these variables are never
> assigned a value. Maybe assignment should be done before Rule 10.

This omission has been added to the processing rules section.


> * Section 5.5, Rule 6, first subrule: after completing the incomplete
> triples, the "list of incomplete triples" must be cleared.

The language in that rule has been clarified.

> * Section 5.5, Rule 9, subrule for plain literals: "... a string created
> by concatenating the text content of each of the child elements of the
> current element in document order ...". I think this is inconsistent
> with the example that contains "<strong>Einstein</strong>" at section
> 6.3.1.3. My proposal is to replace "child" with "descendant" in the
> quoted sentence. In XPath, descendant:: is the transitive closure of
> child::, and that's probably closer to the intended meaning of the rule.

Your proposed change has been made.


> * Section 5.5, Rule 9, subrule for typed literals: "... a string created
> by concatenating the inner content of each of the child elements in
> turn...". I do not fully understand the meaning of this sentence. What
> is the precise meaning of "inner" in terms of a DOM tree? In my opinion,
> "inner" only makes sense if you consider the XML serialization of the
> document (i.e.: the substring between the opening tag and the closing
> tag). However, the rules are DOM-driven, not serialization-driven.

The wording has been clarified in Rule 9.


> * Section 5.5, Rule 9 (and also the last two paragraphs of Section
> 6.3.1.3): this is not a comment, but a question: must the parser descend
> recursively when a non-XML literal has been created by concatenating
> text nodes? I couldn't find a test case for this. In other words, I'm
> not sure which should be the expected outcome of parsing the following
> mark-up:
> 
> <p about="http://dbpedia.org/resource/Albert_Einstein">
>   <span property="foaf:name" datatype="">
>      Albert
>      <strong property="foaf:familyName">Einstein</strong>
>   </span>
> </p>

Yes, in this case, the parser must descend, or do whatever is relevant,
in order to get the descendant text of each node. Therefore, in your
example, the text "Albert Einstein" must be retrieved for "foaf:name".

Section 5.5.9 states that anything with a blank datatype should be
treated as a plain literal. The only time that you do not recurse is
when the type is rdf:XMLLiteral.

We do not have a unit test that tests this particular functionality yet,
but we will add it in the next week or two.

> * Section 5.5, Rule 10: "... after processing the child elements, the
> context can be restored". I propose to change the sentence to: "...
> after processing *each* child element, the context can be restored".
> With the current wording, I understand that the context is restored only
> once, after *all* child elements are processed, and therefore, *every*
> child element share the same context (and this is not desirable).

What you stated is what was intended in the Syntax document, each child
element gets it's own evaluation context. The correction has been made
in the syntax document.


> * Section 9.2: the datatype of @instanceof should be CURIEs (note the
> plural).

Noted and changed in the syntax document.


> Editorial comments / suggestions:
> 
> *  One of my concerns is that the document is not clear enough with
> respect to a question which, from my experience, is a FAQ: "can I use
> RDFa with arbitrary XML documents?". Although Appendix A makes a fair
> effort to clarify this point, however I find the second paragraph of
> Section 3.9 a bit confusing: "The aim of RDFa is to allow a single RDF
> graph to be carried in an XML document of any type, although this
> specification deals specifically with RDFa in XHTML". Please consider
> adding a sentence to unambiguously (Yes/No) settle this question, or
> make a reference to Appendix A.

A sentence has been added to disambiguate this potential
misunderstanding by making a reference to Appendix A.


> * Section "Status of this Document": Incomplete sentence in the third
> paragraph: "These include..."

The section has been removed.  There are no open issues.

> * Section 2.1, description of "@href": the phrase "also an object, but a
> resource" may be confusing (is it an object, a resource, or maybe
> both?). Please consider a different wording, such as "a resource
> object", in order to highlight that it is *a resource acting as an
> object in a sentence*.

The sentence has been changed to be more precise.


> * Section 3.6. In the example, only predicate URIs are abbreviated,
> while subjects and objects are not. Please consider to abbreviate also
> subjects and objects. Alternatively, add a note to indicate that the
> example illustrates how to abbreviate *some* URIs (those acting as
> predicates in the example), and that Turtle allows the remaining ones to
> be abbreviated as well.

The note that we only abbreviate predicate URIs in the document is
specified now, but the mention that Turtle allows any URI to be
abbreviated is also made.


> *  Section 5.1, third paragraph: two kinds of rules are identified here:
> those which are "host language-specific", and those which are part of
> RDFa. I couldn't find more references to these two kinds in the
> document, so the question is: which rules are of the first kind and
> which ones are of the second kind? how are they different? how they are
> relevant to the processing of an RDFa document?

This has been addressed in the updated document.

> * Section 5.2: if I understand correctly, the value of "base" never
> changes during the process of RDFa parsing. This is a difference with
> respect to the rest of the components of the evaluation context. I
> suggest to add a sentence to remark that "base" is an invariant.

The [base] value isn't always invariant. The value of [base] is usually
initialized to the document IRI, but may change if the BASE XHTML
element is used to specify a new base. While it is true that this change
happens before any RDFa property processing, technically the value does
change.

> * Section 5.4.2: what happens if the prefix is void? A reference to
> section 7 might be useful here.

If the prefix is void, the XHTML vocabulary namespace,
http://www.w3.org/1999/xhtml/vocab#, should be used as the prefix.
Section 7 states that a default mapping should be used, but failed to
mention what the "default mapping" for XHTML should be. This has been
fixed in Section 7 of the document.


> * Section 5.4.2, third step: instead of "Combine", I propose "Concat"
> ("combine" might be a bit ambiguous).

The word "concatenate" has been used instead of the word "combine".


> * Section 5.4.4: unmatched end bracket at the end of the second paragraph.

Fixed.


> * Section 9.2: the values of @property, @rel and @rev must match
> "reserved word | CURIEs". Therefore, it is impossible to use more than
> one reserved word, or to mix reserved words and CURIEs, although this
> might not be obvious for some readers. My suggestion is to add a
> sentence making explicit this restriction.

This was never intended as a restriction, you can list multiple reserved
words in @property, @rel and @rev. The language has been corrected to
lift this restriction.

> * Section 9.4, description of "cite", second example: s/@property/@rel
> (@property makes no sense here because section 9.4 describes values for
> @rev/@rel).

The correction has been made.


> * I'm not sure about this one, but I suspect that the @about attribute
> of the two examples in Section 9.4 should be a @resource (otherwhise,
> which is the object of the triple?). Additionally, please consider
> adding a box with the outcome (in RDF) of these examples.

You are correct, the examples have been updated and RDF triple outcomes
have been provided.

> * Please consider using two different background colors for the boxes
> which contain XHTML+RDFa and the ones that contain RDF triples (Turtle).
> I think it would improve readability.

An alternate background color has been introduced.

> * Appendix C.1: some references have brackets, but others don't.

All references have been updated to have brackets.


> * Appendix C.2: the references are not alphabetically ordered.

The references are now alphabetically ordered.

Received on Sunday, 17 February 2008 21:31:49 UTC