- From: Brian McBride <bwm@hplb.hpl.hp.com>
- Date: Mon, 25 Jun 2001 23:24:12 +0100
- To: Dan Connolly <connolly@w3.org>
- CC: Jan Grant <Jan.Grant@bristol.ac.uk>, RDFCore Working Group <w3c-rdfcore-wg@w3.org>
Dan Connolly wrote: > > Jan Grant wrote: > > > > (Don't have an id for this yet) > > > > Re: Brian's test cases at: > > > > http://www.w3.org/2000/10/rdf-tests/rdfcore/rdf-containers-syntax-vs-schema/ > > I haven't looked at all of them in detail, but I see > several that look broken to me. Is there some > explanation for the design that results in these > results? I don't see it at a glance. The rational is documented in: http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Jun/0122.html as ammended by: http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Jun/0185.html > > > > > Test 1: fine (although a note that ntriples definition needs expanding > > to include "\n" and "\r" in WS) > > please, no. keep each triple on one line. > > > Test 2: yes. > > yes. > > > Test 3: yes, although this is simpler than test 2 (and subsumed there?). > > Suggest you change foo:Bar in test 2 to a normal bag. > > hmm... having rdf:li turn into rdf:_nn outside > of rdf:Bag/Alt/Seq looks like a design change, to me. Not sure exactly what consititutes a design change. This proposal: o will generate the same triples for any RDF/XML which is legal according to the stricter interpretation of m&s, i.e. restricted containers o does not extend the expressive power of the language in that anything that can be expressed under this proposal can be expressed using the stricter interpretation of M&S o enables correct processing of sub classes of the containers, even by a non-schema aware parser. o simplifies both the grammar and the parser implementation o has no identified disadvantages > > It's interesting, but can we reasonable expect implementors > to have gotten that from the original spec? An implementor after reading the original spec would note that <rdf:li... matches the property element production and would have to decide how to process it in that context. Such an implementor might note that there is no property rdf:li mentioned in m&s and might also give some weight to the fact that such a property is not mentioned in the RDF Schema candidate rec either. An implementor could take one of three main options: o regard the statement as illegal o generate an rdf:li property, even though there is no such property in the rdf namespace o translate the rdf:li to rdf:_nnn Given the practical benefits of the last of these choices (will handle subclasses of containers), and that it breaks no rules (ordinal properties have no domain constraints) this seems like a reasonable choice for an implementor. > > > Test 4: yes (with a lamentation about the last alternative of production > > 6.12 again) > > > > Test 5: ye-e-es*. I'm not going to quibble about this because it's truly > > a corner case. > > This looks broken to me. It is certainly strange. However, I don't know of any grammatical constraint violated by: <rdf:_1/> I don't really care which way we go on this one. I set out my reasons for having a marginal preference for allowing it in: http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Jun/0237.html and subsequently Art pointed out the question of whether <rdf:_nn ... was legal as a typed node. This doesn't seem like a question to spend much time on. > > > > > Test 6: yes. (the last case is horrific though :-) ) > > > > Test 7: yes. > > > > Test 8: yes. > > > > Error case 1: yep. > > Really? "rdf:li is not allowed as as an attribute" > Why not? Another marginal call. Personally I'd have allowed it and defined it to mean rdf:_1, DaveB preferred to disallow it - as it was another pretty arbitrary call - and Dave has written a parser and I haven't, I went with his preference. Brian
Received on Monday, 25 June 2001 18:26:14 UTC