Math IG comments on CDF Last call documents

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Math IG comments on CDF Last call documents

David Carlisle




Math IG comments on the Last Call CDF documents:

WICD Core 1.0
http://www.w3.org/TR/2005/WD-WICD-20051219/

WICD Full 1.0
http://www.w3.org/TR/2005/WD-WICDFull-20051121/

WICD Mobile 1.0
http://www.w3.org/TR/2005/WD-WICDMobile-20051121/

Compound Document by Reference Framework 1.0
http://www.w3.org/TR/2005/WD-CDR-20051219/


Summary
=======

The current Framework (and hence the profiles defined based on that framework),
do not support features necessary for display of compound document
formats such as XHTML+MathML, and which have been available in common
desktop browsers for many years. The Math Interest Group urgently
request that the Framework (and Core and Full profiles), support the
automatic determination of the size and alignment of the rendered
referenced (or included) language fragment.




Historical background
=====================

As you will be aware, MathML has long been a primary example of a W3C
Recommendation designed for use in a Compound Document Format, having
been first issued as a W3C Recommendation in 1998 within a few months of
the XML recommendation.


Common desktop browsers have been capable of displaying (X)HTML+MathML
documents by reference since the initial recommendations. (Roughly
speaking Internet Explorer 4 and Netscape 4 era browsers). The
mechanisms for referencing external MathML content differed between
MathML systems and browsers (applets, plugins, object tag or embed tag,
etc) They also suffered from problems with spacing and alignment
although that could be overcome to a certain extent using scripting
interfaces to modify alloted size.

Similarly common desktop browsers (IE 5.5, IE6,
Mozilla/Netscape/Firefox) have been able to display XHTML+MathML "CDI"
format markup for 4 years or so. Here the situation is rather better
than in the CDR case, standard markup can be used, although differences
in browser internal interfaces mean that it is more difficult than one
would like to manipulate the resulting DOM from script.

Thus it has been apparent for at least 8 years that a recommendation was
needed specifying the markup and APIs that should be used to provide
cross platform access to this capability and the Math Interest Group was
very supportive of the creation of the Compound Documents activity.

Unfortunately there appears to be a real danger that the current CDF
working drafts are standardising a framework that would not support
MathML (or any language with similar requirements) at all.

We understand that the current priorities are aimed at the Mobile and
other small footprint applications, and that MathML would not be
included in the Mobile profile, but it is Essential that the _Framework_
support MathML, and highly desirable that the Desktop profile should
similarly support the possibility of MathML (if not actually requiring
MathML rendering).



While standardised access to DOM scripting and interaction is desirable,
the most fundamental requirement is the ability to _display_ the
embedded language (MathML in our case). The main requirement here is
that there has to be negotiation between the renderer of the host
language and renderer of the embedded language as to the screen area and
position. The size of a mathematical expression can _not_ be specified
in the markup, it must be calculated by the MathML renderer (as the size
and alignment depend on properties of the rendering engine, current
fonts, lineheights and so on, and thus further depends on the state of
the CSS engine). Both the width, and the vertical positioning of the
embedded rendering must be calculated, so as to align the baseline of
the mathematical expression with the baseline of the surrounding text.

In the case of CDI formats, this size negotiation is available in IE
(via its activex component interfaces, and in mozilla browsers, where
the mathml rendering is added as a native extension) in the older CDR
formats using plugin and applet markup, it is possible to use javascript
to manage the size negotiation, but again the functionality is there
(and has been for many years), what was lacking is any standardised
interface.


The requirements for such a compound document rendering were outlined in
this 1998 submission to the Math Working Group
http://www.w3.org/Math/W3CDocs/mathmlrequ.html
and for a more modern expression of the requirements, a presentation at
the W3C's CDF workshop:
http://www.w3.org/2004/04/webapps-cdf-ws/papers/designscience.html


The nearest the current documents get to discussing the size of the
rendered content is
3.3/1 Rightsizing
http://www.w3.org/TR/2005/WD-WICD-20051219/#rightsizing
which is unfortunately totally inadequate, it is not possible to put the
size of a mathematical expression explicitly into the markup, it depends
on so many factors, and in particular it depends on the MathML rendering
engine being used, and on user defined CSS stylesheets which may alter
the ambient environment such as current font size.



The CDR framework document gives an example of a
XHTML+MathML document (using inclusion rather than reference) however the
example is over simplistic as it uses a displayed equation so doesn't
demonstrate the essential ability to be able to render inline equations
such as E=mc^2 with the equation forming a natural part of the text
stream, using the current text size, and with letters correctly aligned
on the baseline of the surrounding text.


David Carlisle
Co-Chair Math Interest Group
Writing on behalf of the Group


________________________________________________________________________
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
________________________________________________________________________

Reply | Threaded
Open this post in threaded view
|

Re: Math IG comments on CDF Last call documents

Anne van Kesteren-2

On Sat, 28 Jan 2006 00:19:55 +0100, David Carlisle <[hidden email]>  
wrote:
> The current Framework (and hence the profiles defined based on that  
> framework),
> do not support features necessary for display of compound document
> formats such as XHTML+MathML, and which have been available in common
> desktop browsers for many years. The Math Interest Group urgently
> request that the Framework (and Core and Full profiles), support the
> automatic determination of the size and alignment of the rendered
> referenced (or included) language fragment.

This is entirely delegated to CSS which defines exactly what should happen  
for replaced elements. I suggest the Math IG raises its issues with the  
CSS WG instead given that the CDF WG can't change the rules of how the  
size of replaced elements are to be determined.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


Reply | Threaded
Open this post in threaded view
|

Re: Math IG comments on CDF Last call documents

David Carlisle


Anne,

Am I correct to assume that was a personal response, not the official
CDF  WG response to the last call comment?


> This is entirely delegated to CSS which defines exactly what should happen  
> for replaced elements.

It is entirely within the remit of the CDF group to specify how the
compound document, once assembled by reference, is exposed to CSS (or
anything else).  Plugins for netscape 4 era browsers designed to support
compound documents have API calls to expose the natural height depth and
width of the fragment, so allowing the size to be set (typically in that
era, by just document.write-ing a modified object or embed tag). At the
very least, anything aiming to be a "compound document framework" must
standardise the essential feature of setting the size. Even so having to
make explicit calls in script to modify the object tag is of course
rather a poor version of CDF support compared with the rather more
natural, automatic resizing on elements from "foreign" namespaces as has
been available in IE since 5.5 and mozilla since 0.9.something (that is
for years), so given that this is 2006 not 1996, one would have hoped
for rather more than a set of calls to allow size determination. To have
not _even_ that is rather shocking, to be honest.


If the intention is to develop a framework for making very simple
documents on very constrained devices, then fine, there is nothing wrong
with that, but don't call it a "compound document framework" as the
suggestion that a system which implements just the features suggested by
this framework is capable of rendering a compound document of any
complexity is completely misleading.

> I suggest the Math IG raises its issues with the  CSS WG instead

The interaction of Math and CSS has been on the agenda for CSS and Math
for some time, and if there are issues that would need CSS WG input then
clearly we could take those up with the CSS group, but the present
issues are with CDF rather than with CSS.

David
This is a personal response, not to be confused with the last call
comment which came from the Math Interest Group.

________________________________________________________________________
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
________________________________________________________________________

Reply | Threaded
Open this post in threaded view
|

Re: Math IG comments on CDF Last call documents

Anne van Kesteren-2

On Sat, 28 Jan 2006 19:19:47 +0100, David Carlisle <[hidden email]>  
wrote:
> Am I correct to assume that was a personal response, not the official
> CDF  WG response to the last call comment?

Yes. Sorry for not explictly saying so.


>> This is entirely delegated to CSS which defines exactly what should  
>> happen
>> for replaced elements.
>
> It is entirely within the remit of the CDF group to specify how the
> compound document, once assembled by reference, is exposed to CSS (or
> anything else).

I'm not sure what you mean here. I'm just talking about how to determine  
the size of a replaced element. <object> would be an example of a replaced  
element.

The rules for determining the 'width' are described here:
  <http://www.w3.org/TR/2005/WD-CSS21-20050613/visudet.html#inline-replaced-width>
  <http://www.w3.org/TR/2005/WD-CSS21-20050613/visudet.html#q7>

The rules for determining the 'height' are described here:
  <http://www.w3.org/TR/2005/WD-CSS21-20050613/visudet.html#inline-replaced-height>
  <http://www.w3.org/TR/2005/WD-CSS21-20050613/visudet.html#q7>


> Plugins for netscape 4 era browsers designed to support
> compound documents have API calls to expose the natural height depth and
> width of the fragment, so allowing the size to be set (typically in that
> era, by just document.write-ing a modified object or embed tag). At the
> very least, anything aiming to be a "compound document framework" must
> standardise the essential feature of setting the size.

It is not clear to me at all what this means. Are you talking about  
interfaces like (for setting the size):
  <http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/>

I assume that with the other things you mean various interfaces from  
"DOM0" like innerWidth and all that. I'm not sure why the CDF WG would  
have to look into those. That seems rather something for the Web APIs WG  
to sort out.


> Even so having to
> make explicit calls in script to modify the object tag is of course
> rather a poor version of CDF support compared with the rather more
> natural, automatic resizing on elements from "foreign" namespaces as has
> been available in IE since 5.5 and mozilla since 0.9.something (that is
> for years), so given that this is 2006 not 1996, one would have hoped
> for rather more than a set of calls to allow size determination. To have
> not _even_ that is rather shocking, to be honest.

That is a completely different thing. In that case you no longer have to  
deal with a replaced element. (By the way, since when does IE have any  
support for namespaced documents?)


> If the intention is to develop a framework for making very simple
> documents on very constrained devices, then fine, there is nothing wrong
> with that, but don't call it a "compound document framework" as the
> suggestion that a system which implements just the features suggested by
> this framework is capable of rendering a compound document of any
> complexity is completely misleading.

It is still not entirely clear what you mean with all this. What  
complexity? Most of the problems the CDF WG deals with are already solved.  
We just say how they are solved. Could you perhaps give some clear  
examples that are not covered by the CDR Framework or its dependencies?


>> I suggest the Math IG raises its issues with the  CSS WG instead
>
> The interaction of Math and CSS has been on the agenda for CSS and Math
> for some time, and if there are issues that would need CSS WG input then
> clearly we could take those up with the CSS group, but the present
> issues are with CDF rather than with CSS.

Good to hear. I hope that when you or the Math IG provide some examples  
I'll understand the problem better given that I believe the problem is a  
solved problem and that what you want in particular has to be solved by  
rewriting parts of the algorithm as defined in section 10 of the CSS 2.1  
specification. (Given that it is a solvable problem.)


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


Reply | Threaded
Open this post in threaded view
|

Re: Math IG comments on CDF Last call documents

David Carlisle


> 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
________________________________________________________________________

Reply | Threaded
Open this post in threaded view
|

Re: Math IG comments on CDF Last call documents

Anne van Kesteren-2

On Sun, 29 Jan 2006 01:04:25 +0100, David Carlisle <[hidden email]>  
wrote:
>> 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.

That example is non normative and is about a section explaining the  
differences between CDI and CDR. The document itself is about CDR as  
should be clear from the title from section 2. However, I can see that it  
could cause some confusion.


>> (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.

Ah, that explains it.


> 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.

I think DOM Level 3 Core (and earlier iterations) already covers documents  
using multiple namespaces from a DOM point of view.


> 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.

This is really a CSS issue like I said before. CSS defines the rules for  
determining the height and width of a replaced element.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


Reply | Threaded
Open this post in threaded view
|

Re: Math IG comments on CDF Last call documents

Anne van Kesteren-2
In reply to this post by David Carlisle

On Sun, 29 Jan 2006 01:04:25 +0100, David Carlisle <[hidden email]>  
wrote:
>> 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).

Actually, given  
<http://www.w3.org/TR/2005/WD-CSS21-20050613/conform.html#intrinsic> I  
think the "problem" can be solved within MathML. If the MathML layout  
model defines a way to calculate the intrinsic 'height' and 'width' of a  
MathML document (this would need to be defined, taken into account  
embedded HTML and all that) I see no reason it can't already work just  
fine when embedded through <object> given the rules from CSS 2.1 for  
replaced elements.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


Reply | Threaded
Open this post in threaded view
|

Re: Math IG comments on CDF Last call documents

David Carlisle


> <http://www.w3.org/TR/2005/WD-CSS21-20050613/conform.html#intrinsic> I  
> think the "problem" can be solved within MathML. If the MathML layout  
> model defines a way to calculate the intrinsic 'height' and 'width' of a  

Intrinsic dimensions
    The width and height as defined by the element itself, not imposed
    by the surroundings.


and baseline?  Image formats are OK just with height and width but
textual formats need hight depth and width. So that the baselines line
up correctly.

Also the natural (intrinsic) height of a math fragment _is_
affected by the suureoundings, in particular the current font size
which comes from css, browser settings or whatever.


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
________________________________________________________________________