[
Lists Home |
Date Index |
Thread Index
]
That and a bit of maturity from the professionals. How often
do we go into these meetings prepared to skewer a submission
because of the source? By example, wasn't the original
submission for XSD from Microsoft a lot simpler than XSD?
Wasn't the VML submission a lot simpler than SVG?
A tough ability to learn is knowing the good thing when we see it,
rather than trying to find another thing because of the source.
It's human, but wow, it can create collateral damage. Wishful
thinking is at the heart of many a failed business.
I don't expect Mike to answer this because he is now the
source. But company submissions ARE extreme specwriting.
As to *permanent* Extreme committees, I don't like these
any more than what we have. The two-year limit might not
be the solution but it has the desirable feature of a schedule
with a Due Date. One can get extensions. If it takes
longer than two years given due diligence (ISO is very
nasty about schedules but forgiving if due diligence
is provable), maybe it isn't ready for the mill. What
I worry about are the self-perpetuating committees that
find they like each other, want to be together, and keep
on keeping on past their capacity to produce timely hits.
After all, it's fun to travel, see one's name in the trades
and on the covers of the specs, get lecturing gigs, get
to drink with one's heros, and destroy hotel rooms without
having to learn new material.
In the music business, they lose their label deal and
go indie, or form new bands. Their managers are likely
already working for the label.
len
From: Michael Champion [mailto:michaelc.champion@gmail.com]
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.
|
