- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Thu, 18 Oct 2001 09:55:05 +0100
- To: 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. Jeremy
Received on Thursday, 18 October 2001 04:50:45 UTC