xml-dev - Re: Realistic proposals to the W3C?

["Clark C. Evans" <cce@clarkevans.com>]

On Mon, 16 Oct 2000, Daniel Veillard wrote:
> On Mon, Oct 16, 2000 at 08:33:23PM +0100, Matt Sergeant wrote:
> > On Mon, 16 Oct 2000, Clark C. Evans wrote:
> > > > Insist on an open source reference implementation?
> > > 
> > > Absolutely.  Only, call me strange, but I would go 
> > > one step further and say that the reference 
> > > implementation *is* the recommendation and that 
> > > any other explanatory documents are secondary.  
> > 
> > No! Please god no.
> 
> yes I second that. sorry but all attempts at simply building "reference 
> code" was just an exercize in insanity ! I would not make the software
> normative ...

Ok.  There is another way to skin this cat.

1.  Software implements a process (that given particular
    state and input produces a particular output).

2.  The goal of the specification is to describe this
    specific process so that it can be automated by
    a machine _and_ understood by a human.

3.  Describing the process in English or other natural
    language tends to have many possible interpretations
    into a machine description, and can lead to different
    implementations based on different understandings.

4.  A machine description of the process is too incomprehensible
    and not useable by people who have to understand how 
    the machine works, or may include items that are required
    for the machine's operation (Java semantics, for instance)
    and not for the process per sae.

Thus, I now assert that a "normative" reference for a specification
should include:

A.  A rigourous machine description

B.  A fuzzy human description

C.  A feedback mechansim to correct when A and B 
    get out-of-sync, due to an error or inconsistency
    in one, the other, or both descriptions of the process.

Do you agree here?  XSLT has been an unqualified success 
since it has both A and B.  


One may say that the human description is "normative" -- but 
this is where I part company.  I think both a human _and_ machine
description work together as a larger whole -- where the feedback
mechanism comes to play.

So, the rigourous machine description must ALSO be 
included in the "normative" description of the process, no?

Am I asserting that the machine description must
be a full implementation? Actually, Len hinted at the 
other thing it can be.   You can mechanically describe 
the process using a deductive style (with code), or,
with an inductivestyle (using examples).I think both 
are adequate for the machine description, although a 
mix of both would be preferrable.   Tom DeMarco says 
in his 1979 book on Structured Analysis and Systems 
Design (the red book) something like...

  "Thus, it is the acceptance test suite which is
   really the authorative design document".

He then goes on to describe how a regression test 
suite describes a process by induction; it specifies
particular mappings which the process must perform.
So...  perhaps a regression test suite would
be an acceptable "normative" machine description
of the process?

I'm just not so happy with the fuzzy English/Techize 
being the *singular* "normative" description of the 
processes put forth... look at what happend to the 
namespace recommendation!   I humbly assert that 
if _some_ form of machine description of the spec 
were provided (a state machine that accepted valid
namespace names or a huge laundry list of acceptable
and non-acceptable namespace names), we may have 
avoided a ton of mis-interpretation.  So, I put forth 
the question:

  Is a human description adequate to describe
  a process being specified?  Or do we also
  require a machine description (either reference
  implementation, regression test, or both)?

Best,

Clark