Re: rdf-containers-syntax-vs-schema - Action point from 2001-06-15

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