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

"Daniel W. Connolly" <connolly@beach.w3.org> wrote:
>In message <01I50NSOU83M00DV2K@SCI.WFBR.EDU>, Foteos Macrides writes:
>>[...]
>>	It would be highly desireable for a client such as Lynx if
>>what Brian claimed is possible via content negotiation became a useful
>>reality.  I therefor wondered if he had modified his server to make it
>>truly possible, and if so, perhaps it could be tried with the current
>>Lynx developers' code to see if it really works well, or what might be
>>done to get it really working well.
>
>As I recall, the CERN server 3.0 implements most of this stuff. I
>thought it did mxb too, though I'd have to check with henrik to be
>sure. Have you tried the cern server?

	Yes, I have several hacked versions of the v3 CERN server
installed (to "play with" 8-), and I was a regular contributor to
its development (in the good ole days 8-).

	No, it doesn't yet implement most of this stuff.  The
negotiation is still primarily w.r.t. q=quality (and w.r.t
charset/language via the new headers).  Through the most current,
v4 W3C Reference Library, the presentation and converter structures
are still basically those of the v2 CERN libwww.  In HTFormat.h
there's a comment indictating maxsecs and maxbytes elements, but
they're not actually in the structures.  Instead, they still have
secs and max_secs_per_byte, which are weightings in an equation to
generate a value which isn't used, as far as I can tell, in a
function which still has the comment:  /* bad! */

	In the hacked-for-Lynx libwww, I added a long int maxbytes
element to the presentation and converter structures, and an argument
for it in HTSetPresentation() and HTSetConversion(), with default 0,
meaning no maximum.  If it's set greater than 0, ;mxb=maxbytes is
included in the Accept header.  As you indicated, what a server
should do with it isn't clear yet.  I was thinking of something
simple, like, "if this is the choice based on quality, but it
exceeds maxbytes, drop down to a lower quality".  That could be
a problem, of course, if the object were dynamic, but it would be
very useful for static objects at the origin server, and cached,
unexpired, dynamic objects.

	But to get back to the original point of this thread, I
think that content negotiation is worth playing around with, but
is unlikely to provide (at least, not very soon) a really effective
solution to the problem of presenting math adequately both for GUIs
and for text clients that are really using a "dumb" character-cell
terminal.  I do agree with those who feel that MATH should not
have been dropped from HTML 3.2, and that the expressed reasons for
dropping that, and everything else which wasn't implemented by
Netscape (including U) are just plain spin.  However, MATH is not
in the same category as, for example, FIG, or BANNER, or the PLAIN
and CONTINUE attributes for lists.  The clients which implemented
MATH, and their users, were not fully happy with it, and were (or
should have been) expecting further revisions, perhaps radical.
It should have been retained, but with a clear indication that it
is still *very* experimental and undergoing revision.

	Bear in mind that for a text client really using a
character-cell terminal, without dynamically loadable fonts, even
"simple" markup like SUB and SUP is an anathema.  For MATH, Lynx
totally punted by declaring it as literal (Lynx is still a
"traditional" tag and attribute soup handler, and can do that 8-).
It loads the content into an HTChunk, and then displays the raw
markup bounded by "[MATH: " and " :MATH]" labels.  Ugh!  But at
least a Lynx user can use his/her brain to "render" the markup,
and hope that someday somebody might write a for-character-cell
terminals interpreter for that markup (dream on 8-).

	Since there already are high-quality interpreters for
math markup in other "dialects" (I don't know the correct term
for that), if the OBJECT draft pans out, in this case,

	<OBJECT ...>
	 <PRE>
	  ...
	 </PRE>
	</OBJECT>
	
would amount to:

	<MATH ...>
	 <NOMATH>
	  <PRE>
	   ...
	  </PRE>
	 </NOMATH>
	<MATH>

If it's a short stretch of math, it could be included as escaped data,
e.g., for a LaTex interpreter, and if it's a long stretch of math, it
can be fetched from a server (or cache if the client is lucky 8-).
And if it's a plugin that can be provided by any vendor, or hacker,
without need to depend on a "major" vendor to provide it, one might
even discover that a plugin which does a decent job for character-cell
terminals has become available.

	That simple scenero doesn't clearly address the goal of enabling
links within the math, but it could.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Thursday, 23 May 1996 14:06:57 UTC