[
Lists Home |
Date Index |
Thread Index
]
This is a good analysis of the problems in the schema spec, but it doesn't
answer my real question: how does one prevent standards committees from
behaving in this manner?
In my experience, everyone on the group might understand the dangers of
Version One Syndrome, but they still won't drop their individual insistence
on the features that they think are core to the requirement.
I suppose I'm saying that it all depends on assembling the right group of
people who have a common view of what they are trying to achieve (and not
achieve); which is why groups such as W3C are always at their best in their
first three or four years of existence.
Michael Kay
http://www.saxonica.com/
> -----Original Message-----
> From: Robin Berjon [mailto:robin.berjon@expway.fr]
> Sent: 18 August 2005 14:26
> To: Michael Kay
> Cc: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Is Web 2.0 the new XML?
>
> Michael Kay wrote:
> >>No. We need XML Schema so that other WGs know what not to do.
> >
> > OK, so what exactly did they do wrong, and how can other
> WGs avoid doing the
> > same?
>
> I don't claim to know everything that went wrong with the
> Schema WG, but
> here's a quick list of what springs to mind (most specs
> suffer from at
> least one of these, but XML Schema is special in that it has
> them all):
>
>
> Version One Syndrome. Since everyone wants their pet
> feature to be in
> the first version, which then becomes the humongous blob that we have
> come to know and loathe. Doing this, the WG never has a
> chance to do a
> reality check on its requirements before it's way too late to change
> anything.
>
>
> Space Odyssey Sydrome. It was a brilliant idea to separate
> parts 1 and
> 2. Unfortunately, there's a lot more that should be separated
> out of 1
> (Rick posted a list of good examples recently though I can't seem to
> track down the message). A less monolithic spec would likely
> be easier
> to implement (certainly simpler for those of us who only need
> subsets)
> and perhaps simpler to fix.
>
>
> Pompous Vagueness. The spec, especially part 1, works
> incredibly hard
> on being thoroughly impossible to read, yet no obvious
> formalism appears
> when reading it. XQuery for instance learnt from this mistake.
>
>
> Usability Testing. It may sound silly but checking that the
> people who
> will be using your spec are actually able to do so is
> generally a good
> idea. I'm not the smartest monkey on the block, but generally
> when you
> toss me a specification in the Web and/or XML space I
> understand it on
> the first pass and after using it regularly for two weeks I
> only need to
> look up the odd detail (that's definitely the case with
> RelaxNG). I've
> been using XML Schema for three years, on a daily basis, and
> I'm still
> not familiar with it. It's guaranteed that if I hand-author even the
> simplest schema I'll make a mistake. The accumulated time I've spent
> trying to answer XML Schema questions by going through the
> spec with a
> thin comb is measured in months yet it's so convoluted and obfuscated
> that I'll forget the answer after a while.
>
>
> Tools will solve it. A lot of the spec seems to have been designed
> with tools in mind rather than text editors (the human-hostile syntax
> springs to mind), which is also known as the Sweep It Under The Rug
> school of design. When creating an XML vocabulary, apart from
> a very few
> exceptions, and your users require tools to use it, you have
> a problem.
>
>
> There's probably more, but that's all I'm thinking of right
> now. I think
> it's an interesting experience to do. But then I guess I should just
> quit whining and get a job that doesn't require me to deal with that
> specific gorgon (so long as we can keep it from polluting
> other specs at
> random) :)
>
> --
> Robin Berjon
> Senior Research Scientist
> Expway, http://expway.com/
>
>
|
