W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > October 2001

Re: SYNTAX: RDF/XML Syntax WD work

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Mon, 22 Oct 2001 18:33:46 -0500
Message-Id: <p0510103db7fa5ccd00ae@[]>
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
>+ 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.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Monday, 22 October 2001 19:33:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:05 UTC