- From: Bruce Miller <bruce.miller@nist.gov>
- Date: Sat, 15 Oct 2005 15:16:50 -0400
- To: Stan Devitt <jsdevitt@stratumtek.com>
- CC: Paul Libbrecht <paul@activemath.org>, www-math@w3.org
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