On Thu, Nov 2, 2017 at 1:01 PM, Miles Fidelman <mfidelman@xxxxxxxxxxxxxxxx> wrote: > On 11/1/17 10:35 PM, Phillip Hallam-Baker wrote: > >> My specifications are my code. >> >> If you look at any of the protocol specifications for the Mesh, you >> will find a reference section in the back that is generated directly >> from the schema and examples taken from running code generated from >> the same schema. And the running code used to generate the examples is >> the same as the reference code. >> > That's a little bit disingenuous, isn't it - particularly since you've > written quite a bit of documentation beyond your code. I did not say my code is my specification. Which is what a lot of people have done in the past. I develop the documentation and the code at the same time. Of course there are parts of the documentation that are not code, the user guide, requirements, etc. But every specification has normative and non-normative sections. > Beyond that, the point of a specification is to DRIVE implementation & > testing of multiple, interoperable implementations. A reference > implementation is one thing, but as soon as one specific piece of code > (warts & all) becomes the "spec" - it's not really a specification anymore. Reference code is not necessarily the same as production. Production code should be conservative in what it sends and liberal in what it accepts. Reference code should be the other way round. It should complain when the sender fails to abide by the strict specification. We have always considered rough consensus and running code to be important. Building code from specifications is the next logical step.