At 01:29 PM 5/6/2002 -0400, scott_boag@us.ibm.com wrote:
> Encourage document editors to view some of the sentences as "test
> assertions" and to write them in a style that conveys precisely
> what they declare. Explore possibilities for machine processing of
> testable sentences in the future.
On Mon, 6 May 2002, Jonathan Robie wrote:
> This sounds like it might force a particular writing style and
> constrain the sentence structures used by editors. Am I reading
> too much into this?
>
> I am concerned about anything that would increase the work load or
> the constraints on editors. We've got an enormous amount of work
> to do as it is.
On Mon, 6 May 2002, Charles McCathieNevile wrote:
> Well, in order to be able to test specification implementation it
> is helpful to impose these constraints on the way the spec is
> written. I agree that it adds to the already significant workload
> of editors who are not doing this, but I think it is an important
> part of ensuring the quality of our specifications to enable them
> to be tested.
There are many ways to "enable our specifications to be tested". And
we should not forget that ability to test is not the only goal.
An ideal specifications would be both readable by humans and testable
by machines. Most current specifications, especially complex and
interesting ones, do not satisfy both of these properties. There can
be two general directions for improving the situation:
- making humans write machine-testable text (code)
- making machines understand human-oriented text
Some steps can be done in both directions. For example, making every
bit of a spec addressable is not much extra work for humans and helps
machines a lot.
Interestingly, having smart enough machines is sufficient for humans
to write testable specs because a smart machine would tell the author
whether what s/he just wrote is testable. Compare this with writing
poems using pre-declared Java identifiers to avoid spelling mistakes
and having a spelling checker that highlights misspelled words as you
type your poem.
Personally, I do not like the idea of making humans write more code
than they already have to. I think it is a counter-productive approach
in the long term, especially since not all real specifications can
have 100% test coverage (some requirements cannot be pragmatically
tested at all).
Making spec bits addressable is as far as I would go [today and within
W3C scope]. My understanding is that we already have the tools to make
such addressing. And, practically speaking, it is not too much work to
apply any given addressing scheme to address every interesting piece
of a given specification. Do we really need a one-for-all standard
that editors would be mandated to use?
Thanks,
Alex.