On 8/19/05, Dave Pawson <> wrote:
> I wonder if the lessons of XP could be applied here? Given a two year
> cycle, prioritise the required features and deliver what you have at the
> end of the period,
> i.e. down the features list from most to least important.
There has been talk (I can't find a public reference so I won't say
more, maybe Liam can?) of a new type of group that would do more
experimental "design by committee" work that would result in a
specification or other work product that had no claims to be a
standard. Presumably a regular working group could then pick up such
a spec, refactor / refine / test / clarify it and then see it through
to Recommendation status.
Details aside, I think that is one thing that would address some of
the problems noted here, especially Len's long-standing insistence
that "specification" and "standard" be clearly separated in people's
minds.
Or to put it differently, "extreme specwriting" is probably going to
be a very useful way to get useful specs written, but there's also the
reality that the whole notion of a "standard" implies a waterfall
process since it is hard to refactor a standard without breaking
applications. XSD clearly illustrates this -- to go back and fix the
apparent mistakes would create an awful lot of havoc. Reasonable
people can disagree whether that havoc would be worthwhile to clean up
XSD 1.0, but I don't think anyone disagrees that we really want to
avoid being put in this situation again.