- From: Dan Connolly <connolly@w3.org>
- Date: Wed, 27 Jun 2001 12:08:20 -0500
- To: Brian McBride <bwm@hplb.hpl.hp.com>
- CC: Jan Grant <Jan.Grant@bristol.ac.uk>, RDFCore Working Group <w3c-rdfcore-wg@w3.org>
OK; I'm satisfied. For the decision record, please cite the part of the spec that's relevant to... > o enables correct processing of sub classes of the containers, even > by a non-schema aware parser. as rationale for this decision, and cite some part of the spec that we're deciding is in error (a grammar production?). Brian McBride wrote: > > Dan Connolly wrote: [...] > > 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. [...] -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Wednesday, 27 June 2001 13:09:27 UTC