- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Wed, 17 Oct 2001 11:10:19 +0100
- To: w3c-rdfcore-wg@w3.org
I have had a look over revision 1.67 and wanted to make a few points
about the syntactic rules.
Left-to-right priority A | B | ...
==================================
In the one case where I think you're relying on this, it doesn't work.
I suggest dropping it; such procedural readings are usually asking for
trouble.
I'll give an example of how it doesn't work and then give two different
solutions (that do? ;) ).
e.g. (without namespaces)
<rdf:RDF>
   <rdf:Description>
      <rdf:value rdf:parseType="Resource">String</rdf:value>
   <rdf:Description>
</rdf:RDF>
The propertyElt '<rdf:value rdf:parseType="Resource">String</rdf:value>'
does match parseTypeOtherPropertyElt and does not match
parseTypeResourcePropertyElt.
It makes no difference that parseTypeResourcePropertyElt comes first, it
doesn't match.
Solution 1 (my preference)
==========================
  Drop parseTypeOther altogether.
  It won't make any difference in practice to what implementations do. 
  It is not the job of a spec to specify how implementations should
handle bad input unless it specifically gives future compatibility. I do
not believe that specifying rdf:parseType="foo bar" gives that.
Solution 2 (probably also helpful anyway)
=========================================
  Text like:
  "The productions propertyAttr and parseOther which match attributes
with arbitrary values (CDATA) do not match any attribute which is more
specifically matched by any other production in the grammar."
I note that without this text the perverted could have a reading of
emptyNode matching
<rdf:Description rdf:ID="foo" rdf:about="#bar" rdf:aboutEach="#fooBar"
/>
where we have one specific attribute (I don't know which one) and two
propertyAttr's.
That is deliberately misreading the spec. and I don't think it's
important.
Merging of empty property elt productions
=========================================
It is unclear which way we're going with triple production.
If we leave it completely out of a schema which specifies legal RDF/XML
then the three productions emptyPropertyElt,
emptyParseTypeLiteralPropertyElt and emptyParseTypeResourcePropertyElt
can be merged into:
   start_element([namespace_name]=any,
              [local_name]=any,
              [attribtues]=set(idAttr?,parseLiteral?,parseResource?)
   end_element()
parseType=Resource of course does produce rather different triples ...
Jeremy
Received on Wednesday, 17 October 2001 06:05:47 UTC