Re: Math IG comments on CDF Last call documents

> That is a completely different thing.
well it's CDI rather than CDR in the current terminology, it is though
what the mathml example  in your document uses.

> (By the way, since when does IE have any  support for namespaced documents?)

since 5.5. The interfaces are hmm not quite as one would desire, but
they are there, and are crying out to be standardised rather than
ignored. You can send _today_ (and for some years) a standard dtd valid
xhtml+mathml document to IE wth an application/xhtml+xml mime type and
it will render it fine. You need to use a free third party component to
render the mathml of course, but that component only has access to
public IE APIs it isn't using any IE internal code. The same document
can be sent to mozilla and it will be similarly rendered. This is
compound document rendering in action as it has been for 4 or 5 years.
The main down side is that while rendering works cross platform, the
internal DOMs are completely different (IE exposes an HTML DOM with XML
islands, more or less, and mozilla exposes an XML DOM) Standardising
what is supposed to happen at the DOM level so that later implementers
can implement something that can host portable cross platform
interaction is something that one might have expected to have been at
the heart of what a compound document group was about. see for example
http://www.dessci.com/en/products/mathplayer/author/creatingpages.htm#InteroperabilityConsiderations
or for an alternative (older) scheme that requires a bit more markup in
the document:
http://www.w3.org/Math/XSL

> Could you perhaps give some clear  
> examples that are not covered by the CDR Framework or its dependencies?

More or less any example of XHTML+MathML is not covered, whether you
consider an XHTML+MathML (CDI) document which isn't really covered at
all by the current specs (although an example is given) or a CDR document
using some <object reference. In this latter case (which experience over
the last 8 years shows is a very much inferior solution, generally) The
CDF framework needs to specify _some_ way in which the baseline can be set.

See for example Techexplorer (originally IBM, now Integre) that has an
activex component version similar to the mathplayer component mentioned
above, and similarly automatically generates size, but in the old NS 4
plugin version it offers at least a scripting interface so that you can
ask the plugin what size attributes to put on the object tag

http://www.integretechpub.com/docs/techexplorer/Help/Scripting/Embedding.html

This is pretty obviously second best, but it is the _minimal_ level of
support needed to be able to adequately render mathematics. (and it's
been available since the 90's sometime, I forget quite when). (That page
has examples showing what happens if you _don't_ use the scripting
interface. (both just as images, you don't need the plugin to see the
example). The example actually references tex markup rather than mathml
but the system also does mathml.

So really the mechanisms that are in the CDF framework for referencing
external language fragments should support automatic determination of
size and baseline, or failing that, if you just want to use <object
you'd need to specify at minimum that any plugin claiming adherence to
the CDF framework offered API to at least find out what height depth
width the thing should be.

> Most of the problems the CDF WG deals with are already solved.  
> We just say how they are solved.

Quite, the current specs appear to have missed 10 years worth of
experience in rendering compound documents and are proposing to
standardise the non-support of MathML or any other similar language.,
that is basically any compound document format that isn't just including
an image (including svg as an image format for the purposes of the
discussion).

Note that even just returning a rectangular area with height depth and
width is not ideal (and less than is implemented in Mozilla) ideally the
enbedded fragment should take part in line breaking in the surrounding
paragraph, so may generate one or more distinct areas. However just
returning a single rectangular area (as happens in IE) would be
acceptable for a 1.0 version of the framework. Note though that you need
to have both height and depth, just total vertical size makes sense for
image formats but is no use for textual formats where you need to align
the baseline of the text in the fragment with the baseline of the
surrounding paragraph.

David


________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

Received on Sunday, 29 January 2006 00:05:26 UTC