[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: Jonathan Robie Sent: Thursday, May 29, 2003 10:04 AM
> To: K. Ari Krupnikov
> Cc: Paul Prescod; xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Why Standards?
>
> [A small company] can also get visibility by being seen as a leader that
> helped develop the query language.
[in a standards committee]
True enough, but that has led us to a somewhat pathological situation where
OASIS TCs and W3C WG's have an unmanageable number of people involved
mainly to get visibility or to jump on what looks like a bandwagon. (The
clearest example right now is the WSBPEL TC at OASIS, which has more than
100 members).
> (SAX is one of the few examples of a de-facto standard developed by a
> mailing list, outside of a formal standards process.)
One is tempted to speculate about the lessons for standardization that SAX
offers. Maybe the folks who wrote SAX just plucked the low-hanging fruit,
and it's all gone now. But maybe the fact that it was done by "extreme
specwriting" -- the "customers" were represented, there was a "what's the
simplest thing that could actually work?" mindset, there was a willingness
to learn from what went before but also to refactor it as necessary --
accounts for its success.
> resistance to learning proprietary technologies such as proprietary APIs
> or query languages makes the market reluctant to adopt innovative
> technologies from smaller companies.
[bringing in the namespaces thread, risking trolldom, and realizing that
hindsight is 20:20!]
Subject: Re: [xml-dev] Vocabulary Combination and optional namespaces
From: Sean McGrath <sean.mcgrath@propylon.com>
Date: Fri, 30 May 2003 06:38:05 +0100
> Namespaces cause more problems than they fix. This has been my
> experience, and the experience of the 20 odd XML developers who work for
> Propylon over the last couple of years. Perhaps our
> experience is unusual but I doubt it. More often than not, when you go
> into new client engagements to
> sort out XML problems, we find XML transwrecks in the hallways.
Maybe the market SHOULD have been more skeptical of this particular
innovative technology even though it was blessed by the W3C. I can
certainly understand why smaller companies participate in "computer science
by committee" projects, but I'm beginning to wonder if this isn't one of
those ideas that seemed like trusims in the late '90s but the industry now
needs to un-learn. Really simple/powerful ideas (I'm thinking of the
essence of HTML, and CDF/RSS [all flavors], and the essence of XML-
RPC/SOAP/WDDL/etc. [combining XML and HTTP to bring some order to CGI
chaos] come from all sorts of brains more or less at once and thrive like
weeds until the benefits of standardization become obvious. Sure, the
world of competing proprietary technologies is ugly and holds the potential
for vendor-lockin when the Big Guy steps in and buys up the innovators. But
is that *really* any worse than the situation we have today where we're
stuck with "standards" that cause more pain than they cure, and competing
standards organizations that institutionalize industry cleavages?
Stepping up to the pulpit, here's an attempt to say what 'extreme
specwriting' would imply:
* Analysis paralysis is pointless -- There's not enough "science" now for
solid "engineering", so codify existing practice that actually works.
* Avoid "Big Up Front Specs" - Seek to agree only on what is minimally
necessary for a business collaboration or technical interoperability.
* Keep it simple: When it gets ugly, re-factor. Better to break the
implementations of early adopters than to have the whole effort be for
nought because nobody can understand it except the members of the original
committee.
* Have a tight iteration cycle of specs, implementation, testing, and
refactoring/rewriting. If it causes more pain than gain, it fails the
test.
[speaking only for myself, needless to say]
--
|
