RE: Wish List for New Spec

I agree that an independent way of handling equations is far more practical.  I'm here at a University where there is some eagerness for "math".  Problem is that we've gone this route before with wordprocessors and, although the major players implemented it, I dare say less than 5% of the application users bothered to use it.  I think it's too early in the life of html to devote any percentage of commands to the specific math task.  The add-in concept is good.

----------
From: 	Brian Behlendorf[SMTP:brian@organic.com]
Sent: 	Thursday, January 04, 1996 4:53 PM
To: 	Matt Heffron
Cc: 	www-html@w3.org
Subject: 	Re: Wish List for New Spec 

On Thu, 4 Jan 1996, Matt Heffron wrote:
> >> > Math would be number 1 on my list.
> >> 
> >> Anyone else who feels that way, speak up.
> >> 
> >
> >Okay, I will.  :-)
> >
> Me, too.

Sorry to be the sourpuss, but I disagree.  It's not just that it's not 
high on my list - I fear that the effort to create a maths set which is 
rich enough to keep the semantics (i.e., being able to drop an equation 
into Mathematica - hey, can Word do that?) is going to place such a 
burden on HTML that it'll either be ignored by browser implementors or 
even create animosity towards the standardization effort.  Instead, I 
think we should look at the compound document possibilities offered by 
embed/insert, and create (or look for, if it already exists) another data 
type designed particularly for mathematical formula representation.  I.e. 
instead of 

  ...some HTML stuff
  <MATH>(the maths code to represent a^2/b)</MATH>
  ...some more HTML stuff

it's

  ...some HTML stuff
  <INSERT SRC="equation1">a^2/b</INSERT>
  ...some more HTML stuff

Where "equation1" is that separate data type, i.e text/htmaths, 
application/postscript, application/latex, etc.

The benefits:

1) browsers which can't parse the "equation1" data type can still have a 
representation

2) content negotiation allows for the evolution of the "equation1" data 
type *separate* from the evolution of HTML

#2 is really important.  The more HTML grows into a kitchen-sink of data 
type amalgamation, the more pressure there is to constantly "rev" HTML as 
the separate feature sets need to be enhanced.  I.e., who's to say that 
the maths support in HTML 3.0 will be "sufficient"?  It would seem to me 
to be a pretty complex data type if it wants to meet a majority of the 
demands of scientists.  Beyond the complexity is the issue of enhancement 
management - if the two are separated, the community of users who care 
about math support can evolve their standards at the pace they desire, 
separate from the pace at which HTML levels evolve. 

More practically, it means that one doesn't have to wait for new 
revisions of browsers to support that evolution, since EMBEDed (and 
hopefully soon INSERTed) data can be rendered via plug-ins, while the 
HTML rendering capabilities are largely tied to the browsers itself, 
and it doesn't look like that'll change widely soon, i.e. "Can't handle 
the <BLINK> tag?  Here's the Java code to do so" - though I hear the 
Guile browser can do something similar.

Imagine if all inlined images on the web had to be directly embedded in 
the HTML document itself (i.e. <IMG SRC="GIF89alksjef;lhsdkjhafhsklj"> :)
I see this as pretty much the same situation.  If a feature set is 
sufficiently complex, it really belongs in its own data type.

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/

Received on Thursday, 4 January 1996 23:52:29 UTC