Re: <math>, <fig>, ... (fwd)

MegaZone (megazone@livingston.com)
Fri, 10 May 1996 03:16:02 -0700 (PDT)


Message-Id: <199605101016.DAA04606@server.livingston.com>
Subject: Re: <math>, <fig>, ... (fwd)
To: www-html@w3.org
Date: Fri, 10 May 1996 03:16:02 -0700 (PDT)
From: MegaZone <megazone@livingston.com>

Once upon a time schwarte@iwb.uni-stuttgart.de shaped the electrons to say...
>OK, I see  <Object> will supercede <FIG>. <Object> is future, <FIG> 
>is reality in some noncommercial browsers.
>I see that there is no reason to develop <FIG> any further.
>But there still is no reason to eliminate it!
>Leave it in the DTD, and put it in the "deprecated" section when
><Object> is available. 
>Same is true for <math>

That's not the way to develop a spec.

<FIG> was always experimental, it was *never* firmly defined.  That was
it's nature.  Anyone who decided to use it should have made that decision
*knowing* that it was not part of *any* specification and that they
may someday face having to replace it because it died.  That's what
happens.

Another example since my blueprint one didn't take.

V.FC modems - several corporations couldn't wait for the 28.8 spec so
they whipped up V.FC and pushed it as the standard - but they did so
*knowing* they may lose and have to change.  And they did lose, V.34 is
not V.FC so they had to change to support the standard.

<FIG> is like V.FC - all it was was a proof of concept, it was never
meant ot be used and deployed on production sites.  <OBJECT> is like
V.34, it is the standard that takes over.  Just as modem makers had to
upgrade from V.FC to V.34, so to do web authors who used <FIG> need to
replace it.

Why deprecate a tag that was never part of the official standard, that 
was nothing more than a proposal its entire life.  It was never in anything
but known experimental DTDs.

And as for <MATH> - the tag is *still* experimental/in development.  
It *DOES NOT* belong in 3.2 - period.  Experimental, undeveloped tags
should never be included in any standard DTD.  They belong *only* in
test DTDs for developers and the risk takers to use.

If there were a solid interim <MATH> spec (the current one IMHO is not
very stable) then you could put that in - like the interim <TABLE> spec -
but you don't just put in a tag saying - hey, this is in development,
maybe we'll use it someday.  That is not what any standards tracked
document should do.  

You have two trees - the standard, what *is* solid.  And the development
track - what is still primarily ideas and doesn't have a firm definition.

That is why you have development DTDs and you don't throw that stuff into
the standard DTD.

Because the instant you put it in the standard DTD you have de facto put
it in concrete.  If it later turns out during development that the 
documented method is lame, you are stuck - you have to leave it in, at
least for a while, as a legacy implimentation.

And that is pure evil.

<MATH> is not dead - math is still gestating as is yet to be born.

<FIG> was a miscarriage.

-MZ
--
Although I work for Livingston Enterprises Technical Support, I alone am
responsible for everything contained herein.  So don't waste my managers'
time bitching to them if you don't like something I've said.  Flame me.
Phone: 800-458-9966  support@livingston.com  <http://www.livingston.com/> 
FAX: 510-426-8951    6920 Koll Center Parkway #220, Pleasanton, CA 94566