Re: SYNTAX: RDF/XML Syntax WD work

>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