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

On Tue, 21 May 1996, Michal Young wrote:
> At 11:49 AM 5/21/96, Brian Behlendorf wrote:
> >Am I a pariah for thinking that the functionality which <math> hopes
> >to encompass would be much better suited to a different data type
> >altogether, embedded in HTML using <object> rather than trying to
> >squeeze it into HTML proper?
>
> Plausible, but one would need a little more detail of a design to judge the
> advantages and disadvantages.

There are existing formats, such as TeX, LaTeX, whatever data format 
Mathematica can use, GIF's, etc.  Some of those are high-level, some are 
just a bunch of pixels without structure.  If existing data formats are 
insufficient, then whatever effort is going into the <math> proposal 
could be aimed towards a stand-alone DTD.  In my mind it's clear that 
HTML doesn't need <math> to be successful - the question is does <math> 
need anything from HTML.  Is it important to be able to put a form inside 
a derivative equation?  Or a <BR> in a formula?  I don't think it is.  I 
think the only thing existing mathematical representation languages might 
be missing is a hyperlink ability, and adding that on top of an existing 
language might be a lot less work than inventing and refining a new 
language.  

When we started the VRML project, it was obvious that it was not 
appropriate to try and create new HTML tags to represent 3-D objects.  
An SGML basis may have been appropriate, but we chose a different path in 
the end, extending an existing language (SGI's Inventor) to meet our 
needs.

There must be some criterion which people ask themselves when they 
consider the question "is it appropriate to put the functionality of 'X' 
within HTML?".  My criterion happens to be pretty conservative, mostly 
because turning HTML into a complex beast (which it's 90% of the way 
there) would be the best way to kill it as an enabling technology.  

I would consider the needs of the mathematical community to be pretty
complex, so complex that tying the evolution of that datatype to HTML's 
very rocky evolutionary path could be a big problem.  

> > Separating it out makes implementation 10x
> >easier (just distribute plug-ins),
>
> How many plugins?  One for every processor/OS combination?  

I think the days of having to code plug-ins to specific platforms are 
numbered, numbered by how well Java compilers shape up in efficiency.  
Furthermore, using <object> to embed the mathematics, combined with 
proper content negotiation, means that the author can provide high-level 
and low-level representations of the math objects, such that if someone 
is viewing the page with a browser only capable of rendering HTML and 
GIF's, the server could give the user a GIF of the mathematical 
equation.  If it's a text-only browser, the author could generate (to 
their liking/quality control) a text equivalent.  Of course, with Lynx 
2.5 claiming to "Accept:" a bunch of image formats this is something of a 
problem.

> A big advantage
> of staying within html is to stay platform-independent.

Putting it in HTML doesn't automagically implement it in the worlds' 
browsers.  In fact, something as hairy and complex as math support could 
prevent all but the most well-funded browser companies from being able to 
support it (yes, I know it's in arena).  If it's left as something for 
<object> to embed, then browser authors don't even need to worry about 
it.  If we all could agree on a plug-in architecture then math support is 
coded once and that's that.

> On the other hand, one could certainly imagine math markup interpreted by a
> general-purpose applet interpreter.  Provided the interpreter is already
> widely available (e.g., Java) then the portability issue is addressed. And
> if the math markup is reasonably readable as text, browsers without
> interpreter support, or without graphics, might do ok to just present it
> uncooked.

Hmm... it would be interesting to see what that API would look like, 
since rendering decisions take something of a holistic approach, no?
Can the rendering of a specific tag be chunked off to a plug-in?  What if 
I use other non-math HTML commands within the plug-in?

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  |  We're hiring!  http://www.organic.com/Home/Info/Jobs/

Received on Tuesday, 21 May 1996 17:39:03 UTC