[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Avoding a repeat of W3C XSD - was Re: Is Web 2.0
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@g...] 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|