Erratum in REC-rdf-syntax-19990222?

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