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

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

From: Dave Beckett <dave.beckett@bristol.ac.uk>
Date: Wed, 17 Oct 2001 11:37:02 +0100
To: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Cc: w3c-rdfcore-wg@w3.org
Message-ID: <14142.1003315022@tatooine.ilrt.bris.ac.uk>
>>>Jeremy Carroll said:
> 
> 
> 
> I have had a look over revision 1.67 and wanted to make a few points
> about the syntactic rules.

I said I hadn't started hacking that section so, I'm answering quickly

> 
> 
> 
> Left-to-right priority A | B | ...
> ==================================

In short: I'm deleting this.  It was a last minute pre-WD change that
I did and regretted, confirmed with subsequent emails on www-rdf-comments.


> 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.

Yeah; the words here should be more of a hint - qnames thing that
came up recently, might appear.

> 
> 
> 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."


Yeah, maybe I'll merge that in.


> 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.


There are plenty of silly things that could be done, I'm not sure
whether to ban rdf:Description as a property etc. or just not provide
a meaning for them.  Going for latter at present.


> 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()


I was going to remove the empty* terms into the, for example, 
parseTypeLiteralPropertyElt and then have words saying if [children]
is empty then A else B.


> parseType=Resource of course does produce rather different triples ...

Yeah, really a very different thing

Thanks

Dave
Received on Wednesday, 17 October 2001 06:40:15 EDT

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