W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > October 2001

Re: SYNTAX: RDF/XML Syntax WD work (editorial)

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Wed, 17 Oct 2001 11:10:19 +0100
Message-ID: <3BCD590B.DDCA0A4D@hplb.hpl.hp.com>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:41:05 EDT