- From: Joe English <jenglish@flightlab.com>
- Date: Thu, 20 Jul 2000 12:18:14 -0700
- To: www-rdf-comments@w3.org
Hello, In REC-rdf-syntax-19990222, section 6 "Formal Grammar for RDF", the third alternate in production [6.12] ("A") specifies: | propertyElt ::= [...] | | '<' propName idAttr? parseResource '>' | propertyElt* '</' propName '>' | ^^^^^^^^^^^ | | [...] but the subsequent prose ("B") specifies that: | Each propertyElt E contained by a Description element | results in the creation of a triple {p,r,v} where: | [...] | 3. Otherwise [*], the content of E must be another | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | Description or container and v is the resource | ^^^^^^^^^^^^^^^^^^^^^^^^ | named by the (possibly implicit) ID or about of that | Description or container. [*] where "Otherwise" means "E contains XML markup and 'parseType="Literal"' is not specified in E's start-tag". Then the *next* paragraph ("C") states that: | [...] [parseType='Resource'] specifies that the element | content must be treated as if it were the content of a | Description element. (A) and (C) seem to be in agreement (the propertyElt *is* a resource), but contradict (B) (the propertyElt *contains* a resource). Also, the last sentence in (C) states: | The content of an element having a parseType="Resource" | attribute must further match the production for the content | of a Description element. There is no such production in the grammar (besides, this statement is redundant since it's already specified in the grammar -- [6.12] alternate [3] and [6.30] alternate [3]). On a related note, is the verb "contain", when applied to elements (as in "Each propertyElt _E_ contained by a Description element ...) used to mean "directly contains" (as in the XPath "child" axis) or "contains directly or indirectly" (as in the XPath "descendant" axis)? I presume the former, as the latter interpretation would assign properties to resources identified "higher up in the tree" than what seems to be intended. Hm... now that I think about it some more, under the former interpretation a propertyElt 'G' inside a propertyElt 'C' with 'parseType="Resource"' inside a Description element would have *no effect at all*, since 'C' isn't itself a Description element (unless I'm missing something...) Perhaps it would be clearer to delete the qualifier "contained by a Description element" in (B, sentence 1): | Each propertyElt _E_ *contained by a Description element* | results in a triple {p,r,v}... and change "the Description [element]" to "_E_'s parent [element]" in (B, clause 2, "r is:....") And/or change (C, sentence 5) from: | The value 'Resource' specifies that the element | content must be treated as if it were the content of | a Description element. to > The value 'Resource' specifies that the element > must be treated as if it were a Description element > (in addition to its treatment as a propertyElt). Lastly (and this is picking nits), in (B, item 3, sentence 2), "If the content of _E_ contains no XML markup...": What about entity references, character references, and comment declarations? If the RDF semantics is based on the parsed representation (this isn't clear from the spec, BTW), then these won't be present, but then again in this case a propertyElt with subelements won't contain any XML markup either: "markup" only appears in the serialized representation. Presumably this will all be cleared up by the Infoset spec, but at any rate "If _E_ contains no subelements" would IMO be clearer. --Joe English jenglish@flightlab.com
Received on Thursday, 20 July 2000 15:18:31 UTC