Re: consuming the semantic tag (was Re: Subscripts in Content MathML)

Stan Devitt wrote:
> I am not wedded to any particular implementation just
> so long as the user interaction is correct.  The Accept
> header may do it, or failing that UserAgent.

This whole area is a big worry to me; It isn't at all
clear that the existing mechanisms are sufficient and scalable.

For a `straightforward' math site, merely wanting to serve
presentation MathML or images of math, as appropriate,
it is just possible to use the UserAgent.  At present,
there are really only recent Mozilla and IE+MathPlayer
handling MathML.  But as more browsers implement MathML
--- as we all hope they will! ---  this will become more of a
browser sniffing maintenance mess.

I would assume that methods relying on client-side XSLT
would have the same issues:  which agents support XSLT,
and what to transform the math into?

Superficially, the accept header sounds right, but
most (all?) browsers don't send the _whole_ list of
mime types that they can handle; those lists would be
very long.  And even then; the accept header addresses
the mime type of the main document, not the embedded
types. The type application/xhtml+xml sounds good,
but plus _what_ xml? MathML? SVG? UnitsML? the next big thing?
Should this expand (explode) into application/xhtml+mathml,
application/xhtml+svg, application/xhtml+mathml+svg....?

Maybe an HTTP_ACCEPT_EMBEDDED header is needed to list
mime types that can be embedded in any of the `main' types?
(Oh boy! A new spec that we can wait years for people to
implement! :> )

Making the accept charset, encoding or language headers
do double duty seems likely to lead to confusion.

> I agree that the Language header would be overloaded.
> I mentioned it mainly as it characterises the kind of action 
> that we need.
> 
> Basically, an http request is made to a generic URI with enough 
> information embedded in the header so that the server can server 
> can customize the response to take into account the mathml specific 
> information.
> 
> The main thing is that the user should not have to modify 
> the URI to request manually to request a particular version of 
> the document.  (for example, by manually adding  a parameter like  
> ?mathml_include=content,presentation,maple)

I think there is a place for such modified URI's: eg. when the user
might want to download an alternate representation, and when the choices
are open ended, possibly selected from a menu.

OTOH, I strongly agree, that by default there should be mechanisms
which allow the client & server to automatically negotiate the
most appropriate type for the given resource and client.
I'm involved in a `reference work' project where the URI's should
be as close to URN's as possible: permanent, and without the type
embedded; they can point to anywhere within the site, so a
`gateway page' is of limited value.  Besides, users should be able
to record these URI's in various ways (bookmark, in print and send
to others in email, ...) and have the recipient get a version or
representation of the resource that is appropriate for the recipient,
not the one that the original person used.  I don't even want to use
.html vs .xhtml extensions, let alone an extra `view' query!
(at least, not a required one!).

But, sigh, what to do??

-- 
bruce.miller@nist.gov
http://math.nist.gov/~BMiller/

Received on Saturday, 15 October 2005 19:15:19 UTC