- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Mon, 22 Oct 2001 18:33:46 -0500
- To: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Cc: w3c-rdfcore-wg@w3.org
>Hi Dave > >With the danger of rushing in before you've reached anything like a >stable point ... > >I have had a look at version 1.88 and I am decidedly nervous about the >direction you're going with the triple production stuff. > >I fear you're heading for a rerun of M&S section 6 with: >+ too many words >+ that are self-contradictory >and >+ too unclear > > >I am also less than taken with the view that the text describing the >production should be associated with a particular processing model. > >For instance in the subsection "Production node" you say > >[[[ > The following processing is performed before handling any >propertyEltList children and in this order. >]]] > >That is presumably intended in an abstract processing model. >It is in my view, perfectly legal to process the property attribtues >after the property elements, and the resulting n-triple file is an >acceptable rendition of the RDF/XML. > >I would go further and say that the property attributes and property >elements can be processed in any order with the single exception that >rdf:li is converted into rdf:_NNN in document order. > >I also dislike the "in this order" part since many of the steps you then >list are, in fact, interchangeable. > >I fear we have a stylistic clash brewing. > >I feel that it is better if a specification does not over-specify by >indicating superfluous things; whereas you appear to want a >specification that would have helped you write the particular >implementation of RDF/XML that you have in mind. > >I do not feel that it is the job of a specification to assist a parser >writer. The job of a specification is to specify what needs specifying >(and no more or less). If at any point there is a conflict between the >task of assisting the reader in their task (e.g. writing a parser), and >the principle aim of specifying I am clear that the reader should be >left to seek assistance elsewhere. The reader should expect clarity from >a spec, if they want a howto then they may need a different document. I strongly agree with this. Specs should inform, but not constrain any more than absolutely required. If there is a neat way to help a newbie get a parser (or whatever ) written, then put that in a primer or expert-guide document, but not in the spec itself. Pat -- --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
Received on Monday, 22 October 2001 19:33:56 UTC