At 04:50 PM 3/28/01 -0000, dianeb77@... wrote:

>
>I don't like the SQL standard, but probably for some different reasons
>than yours.
>Besides being impossible to read (and getting worse, not better), and
>being developed by an old boys' network, and all that, one thing that
>drives me NUTS is that people who use SQL every day to build
>applications still have no idea what "conforming to the SQL standard"
>means (*), and then get themselves into all kinds of trouble because
>of it. I hate seeing that.
>
>It's not their fault, I don't think, because nobody would expect
>[either the Spanish Inquisition or] the bizarre rules that let
>products that support totally incompatible features and behaviours
>claim conformance to the same standard ... but it's been that way for
>years, through many scars and lessons learned, and nothing has
>changed.
>

The historical problem is easy to understand. SQL started without
a standard; products diverged; and no representative wanted to go
home and explain that his committee outlawed his companies
implementation. The principled solution is to byte the bullet,
flip a coin, and let the losers have a mode setting. In the long
run, everyone will have a mode setting. If the committee actually
wanted a standard, that is what they'd do.

The goal of a standard is achievable given a will. Leave the current
useless standard in place but ignore it (like this is change, right?).
Start over with a standard with a different name, say Sql Transformed
Under Principled Development. Where the existing standard has choices,
pick one, preferrable consistent with other choices. Don't include
anything that hasn't been implemented or isn't well understood.
Give the standard a revision number.

An implementation is compliant with STUPID Rev. X iff it supports
everything in Rev X. Period. The implementation could do anything
else it wanted to, but if Rev X+1 conflicts, it's gotta change before
it can claim compliance.

Repeat until done.

The keys are:

1. No permissible inconsistencies.
2. No design by committee. The committee can pick among
implementations from vendor extentions, research projects,
prototypes. No moronic idiocy like the trigger standard.
3. Compliance is a boolean value, not null.

So we decide whether meta data is case sensitive or not, whether
nulls sort high or low, etc. But no pick one from column a, one
from column b.

>
>The goal of the SQL standard was, historically, application
>portability.

Then it was an absolute, total failure. Everybody but Diane
gets fired. The secretary gets permanently blacklisted.

>
>> "Because even standards committees can't live on air."
>> Ridiculous! What are their expenses? The members have
>> their salaries and travel paid by their organizations.
>> Postage? Maybe they could figure out e-mail and the web.
>> Meeting sites? Maybe some the member organizations have
>> conference rooms.
>
>However, that does not cover the basic distribution costs of the
>finished standards -- printing, inventory, etc. etc. Those are
>incurred by ISO itself, and recovered using a "user fee" model.
>

If they gave it away for free on the web they wouldn't have
printing cost, inventory costs, etc. etc., to be recovered.
I'll contribute $20 to cover the costs of the first month.
I'll even volunteer Ann to teach Melton html (I taught him
Pascal; it's her turn this time).

>
>Excerpts from the ISO FAQ (http://www.iso.ch/infoe/faq.htm):
>
>"Who pays for ISO?
>ISO's national members pay subscriptions that meet the operational
>cost of ISO's Central Secretariat.

My version:

The world pays for a worthless standard everything a company
changes platforms or changes database systems. Arbitrary
differences in base technology costs the world economy at
least 10s of billion of dollars a year, easily enough to
pay the entire AID's medication costs for the continent of
Africa. The only winners are the database companies that
can simultaneously claim compliance with a standard that
professes to encourage portability and absolutely prevent
their users from any semblence of reasonable porting.

The SQL standard is far worse that useless.

>
>Why aren't ISO standards free?
>ISO standards cost money to develop, publish and distribute.
>Someone has to pay. The current system whereby users are
>requested to pay for the standards they use, not only sustains the
>development process but also, very importantly, ensures that the
>balance of independent vs. government, private vs. public interests
>can be maintained."
>

b.s.

>
>I didn't write it, I'm just passing it along ...
>
>
>And, I'd add "while still encouraging innovation at the foundation
>level?"
>

Interbase (I.) did it. Our SQL was absolutely standard compliant.
Innovation was in GDML. Users could pick stupid or smart according
to their requirements. Oh, the two played together nicely.

Jim Starkey