xml-dev - Re: OPEN LETTER: Standards must stand on their own

[Len Bullard <cbullard@hiwaay.net>]

Don't know if I like the idea of multiple namespaces, but..

>James Robertson wrote:
> 
> This has highlighted what I think is
> an important point:
> 
>         "Standards must speak for themselves.
>         They must be clearly 'the right way'
>         to solve the problem. If they require
>         advocates, then they have failed."

Any idea, whether you get beyond it or not, 
requires advocates.  Few ideas which adapt 
existing technology or ways of working are 
accepted with a Duh slap, and a why didn't I 
think of that.  What is required, as has been 
pointed out, is rationale in the face of 
honest differences.

> If a standard is not well received on a list
> like this, then what chance will they have
> in the real world? There, if a standard is
> not liked, it will be ignored. This would be
> a terrible waste for all involved.

You must have been in school when HTML was 
launched.  The debates were real and vigorous.  
There are many reasons not to like a standard 
or an implementation.  The proof and the 
acceptance is in the implementation.  Even then, 
there may be better ideas but the market will rule.  
There have been some very lucid articles on 
ZD-Net and elsewhere as people have begun to 
understand that market rules do not tend to 
benefit the consumer.  Sometimes, it is better 
to question the freebie, investigate the 
claims of originality and appropriateness, 
and understand tech before investing.  That 
is just good sense.  Waste is a fact of industry.
 
> Standards should not be controversial. They
> should not 'innovate'. They should solve a
> problem the 'best way' based on the real
> world experiences of all involved.

Agree and disagree.  There is plenty  
of literature that claims relational databases 
are all you need.  I can cite from experience 
efforts to make PDF the sole accepted standard 
for digital documents in some domains.  World 
experience is not sufficient.  The acclaimed solution 
often depends on the local domain or politic.
 
> If there is no experience to guide us in
> an area, don't create a standard. Wait.
> Experience will come ...

No it won't.  I agree standards should be 
created once products reach commodity status, 
but if you wait for experience you will only 
get a standard no one understands or understands 
why it should be standard.  At some point, as 
the buzzard says to the next buzzard, "Patience 
my ass, I'm gonna kill me something."  Science 
and standards depend on repeatable results.
 
> With respect to the XHTML spec, it means
> that it should go back to draft status,
> and remain there until a solution presents
> itself that is unarguably elegant, and
> practical.

Foolish.  It should be argued over like 
meat in a wolves den.  It is important.  
It should also be noted that wolves 
fight but also live in communal packs.  
They cannot choose to be wolves, and that 
is the difference here.  This group can.
 
> If this cannot be done now, don't release
> the standard. If the world is not ready to
> create a single defensible standard, then it's
> not ready for a spec at all.

And would not be ready for government if individuals 
did not choose to govern.  You live under law or you 
don't.  Civil disobedience is the alternative.  It 
is, for the individual, sometimes the best alternative.  
In other words, if XHTML As Spec'd is unimplementable, 
don't implement it.  Your choice.  If others do and it 
works, then they made a better choice.  This was 
the same choice made about HTML originally.  There 
were better ideas and better systems.  Care to roll 
back the clock to 1991 or stay in the fray?
 
> In conclusion, I would like to draw parallels
> with other standards bodies. The IETF, for example,
> has a very good history with standards. Standards
> such as HTTP 1.1 were released without much fanfare.
> Everyone looked at it, admired it, and in due course
> implemented it. All with very little argument or
> discussion.

Wrong.  Running code and rough consensus.  IETF 
defines working designs which have to be proved 
by implementation.  Very practical.  The difference 
is, the IETF is not a consortium.  Anyone can sign up 
for the debate and get the details.  The argument here is 
about W3C processes that result in decisions not 
justified by rationale.  It creates an atmosphere 
of suspicion, mistrust, and fear.  
 
> Other bodies, such as the ISO, hold the other
> position. People tend to look at their standards
> and become frightened by their complexity. ISO
> standards have a long history of not being used.

Wrong.  HTML is based on an ISO standard.  ISO 
has a long history of responsibility, credibility, 
attention to detail and process, and a reputation 
for good product.  There are many ISO standards 
in use every day, some good, some not as good.  
However, they have produced many standards and not 
all of them succeed.  That could happen to XHTML but 
not for lack of interest.  Again, XHTML is not a 
standard; it is a consortium-owned technology.  
It is the schema for an application.
 
> So I say again:
> 
> Standards must speak for themselves.

No.  Implementations must prove them.  Markets 
can adopt the products.  But people, individuals, 
speak for their work.  That is the primary and 
most defensible argument in this long and yes, 
silly debate.

len bullard


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)