[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Why 90 percent of XML standards will fail
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: Frank Richards <firstname.lastname@example.org>, email@example.com
- Date: Wed, 28 Feb 2001 10:02:35 -0600
The problem is not the term for the work, it is
the results. Does it work and can you find that
out before committing resources to using it?
It is the process, not the term one wants
to look at to evaluate a source. The W3C requires
a period of evaluation presumably based on implementation.
The rule is, as I understand it, if unimplementable, it
doesn't go forward. Now one gets into the quality of
that evaluation: did it wring out all the unimplementable
features? This is different from the problems of ensuring
o all of the specs are encapsulated, that is, don't require
separate overlapping implementations for the same functionality
o some requirement was not well-understood such as the scaling
issues for very large datasets or hidden semantics (the data
model dilemma) that degrade blind interoperability
Either of these can force a loopback in the process and the
loopback is expensive. Again, if you believe that the myth
of internet time prevails and you will lose if you don't
get a minimal victory or 80/20 solution, you go fast and
take territory because your dominant concern is domain.
If you think it is better to try to get as good a handle
on the requirements as you can before building, you spend
more time on the research and evaluation before moving
forward. Most orgs, spec or standard orgs, alternate
between these two approaches. Results vary according to
experience, shifting environments and the ambitions of
the specification/standards authors.
So look at the process, the means to choose the means,
and ask if you want that authority to choose your means.
Then choose wisely.
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Frank Richards [mailto:firstname.lastname@example.org]
Don't use it. The recommendations are put out in the hope that they will
become de facto standards (and perhaps in 'legal time' de jure standards).
If the specifications are either unimplementable or don't solve a real
problem, let them go the way of the ISO 7 layer model or the 'other' ISO
document spec that competed with SGML. (They're still standards, but if they
mattered I'd probably remember their names.)