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

"Daniel W. Connolly" <connolly@beach.w3.org> wrote:
>In message <01I4Z75LICG200FLFS@SCI.WFBR.EDU>, Foteos Macrides writes:
>>
>>	Unfortunately, content negotiation was not included in the
>>HTTP/1.1 ID
>
>What?
>
>Please cite sources! It helps prevent the spread of such
>misinformation:
>
>http://www.w3.org/pub/WWW/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-03
>
>15 Content Negotiation
>A generic resource has multiple entities associated with it, all of
>which are representations of the content of the resource.  Content
>negotiation is the process of selecting the best representation when a
>GET or HEAD request is made on the generic resource.  HTTP/1.1 has
>provisions for two kinds of content negotiation: opaque negotiation and
>transparent negotiation.

	Sorry, too terse sentences that are misinformation out of
context, and misinterpretable even in context.  Here's another try.

	In response to Brian's assertion that HTML markup for MATH is
unnecessary, because math is better handled via content negotiation,
and that:

Brian Behlendorf <brian@organic.com> wrote:
>[...]  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. [...]

I meant to reply that unfortunately -- for that set of assertions in
Brian's massage -- the May 2, 1996 HTTP/1.1 ID (reference above from
Dan) expresses intent for support of both opaque and transparent
negotiation, and their combination, but defers description of the
transparent negotiation algorithm and their combination to as yet
unavailable drafts (can't finish everything at once 8-).  Also, in
it's descriptions of Accept headers for opaque negotiation, it
indicates the traditional q=qvalue parameter for all content types,
and level=number for text/html, but does not reference or appear to
incorporate the wonderful proposals in the February 22, 1996 "Holtman"
ID:
	"Proposed Content Negotiation Definitions for HTTP/1.1",
		K. Holtman
	ftp://ietf.cnri.reston.va.us/internet-drafts/
		draft-holtman-http-negotiation-00.txt

most valuable of which, for a client like Lynx, is mxb=maxbytes

	Although normally Lynx would not send Accept headers specifying
image and other binary content-types, it can be run in a window, with
the DISPLAY variable set, and in such cases on processing its configuration
files and the mailcap file it is likely to have helper apps for such
objects set up, and will send additional Accept headers accordingly.  It
also can be configured to include a number of parameters, e.g. (using
the simple, serial Accept header format):

Accept: text/html
Accept: text/plain;q=0.9
Accept: image/jpeg;q=0.9;mxb=1000000
Accept: image/gif;q=0.8;mxb=1000000
[...]
Accept: */*;q=0.001

but users would be ill-advised to assume that many, if any, currently
deployed servers will handle that fully as intended.

	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.

( I realize it's likely that even if we did succeed in getting it
really working usefully, and sites with special needs, like getting
math displayed decently by both GUI and text clients, made use of
that ability, if the major vendors didn't follow that lead and/or
the great majority of sites did not bother to generate text
equivalents, their useage statistics would "prove" that we don't
exist and didn't deploy, but the illusion that we exist and
succeeded would still be rewarding. :)

				Fote

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

Received on Wednesday, 22 May 1996 20:24:45 UTC