W3C home > Mailing lists > Public > public-cdf@w3.org > January 2007

RE: Math WG comments on latest CDF documents

From: Steve K Speicher <sspeiche@us.ibm.com>
Date: Wed, 3 Jan 2007 13:58:07 -0500
To: "Ron Ausbrooks" <ron.ausbrooks@mackichan.com>
Cc: davidc@nag.co.uk, member-math@w3.org, public-cdf@w3.org
Message-ID: <OF7978FC7C.80B0CB0C-ON85257258.006703C2-85257258.00680F29@us.ibm.com>


For the record, the CDF WG has resolved not to make any changes in the 
current referenced public drafts regarding this issue.   The WG does not 
feel we can define the adequate level of specification needed given the 
timeframe and scope with the current drafts.  The WG has recorded your 
disagreement with this resolution.

This does not prohibit anyone from defining extensions or profiles that 
include MathML or introducing the capabilities that you have outlined.  We 
have left the issue open internally and will attempt to continue to 
collaborate on a solution to this issue in future works.

Thanks for your feedback,
Steve Speicher
On behalf of the CDF WG

"Ron Ausbrooks" <ron.ausbrooks@mackichan.com> wrote on 11/14/2006 01:34:33 

> Steve, and the CDF WG,
> Thank you for your response to the Math WG's comments. Unfortunately, we
> don't feel that our concerns are adequately addressed by it.
> We'd be happy to contribute to a MathML-based profile based on the
> compound-by-inclusion framework. However, MathML may also appear as a 
> document by reference (via an <object>), and we don't feel that the 
> draft provides the necessary support. While restricting consideration of
> layout issues to scalable elements is fine for the SVG-centered profile
> documents (WICD Full and WICD Mobile), it seems inappropriate for a 
> compound document framework. Some brief discussion of layout negotiation 
> objects which are not scalable should appear in the WICD Core document, 
> perhaps even in the Document Object Model section of the CDR Framework
> document.
> Our specific suggestion is to include a specification like the 
>   "The Document Object Model for a child document SHOULD make available 
> the parent methods to return the width, height and depth (or 'baseline
> offset') of the child content."
> Such a stipulation would codify handling of <object> that has been 
> already by some user agents, and has allowed scripting to provide 
> display of inline MathML. On the other hand, we see publication of these
> recommendations without such a provision as implying a step backward.
> We don't believe that leaving such considerations for a MathML-based 
> is the best course, as we don't believe they apply only to MathML. Any 
> document which gives rise to text-like content needs the same sort of
> support.
> If you believe that a provision of this sort is beyond the scope of 
> recommendations, then it seems that that scope excludes essential
> interoperability requirements of MathML objects (and other text-like
> objects). We feel that you should in this case remove mention of support 
> MathML and examples of MathML from them for now, as in our opinion these 
> currently misleading. In particular, the section delineating the scope 
> the CDR Framework document includes the text:
>   "While it is clearly meant to serve as the basis for integrating W3C's
> family of XML formats within its Interaction Domain (e.g., CSS, MathML, 
> We believe that it's misleading to imply that the Framework as currently
> written is usable for a wide variety of languages, and specifically for
> MathML. 
> In any event, we ask that layout (size) negotiation for text-like child
> documents be added as a formal requirement for the Compound Document by
> Inclusion work. We would suggest that the CDR Framework document 
> state that automatic size negotiation between parent and child is not
> currently supported by CDR but will be addressed in CDI; this 
> should then include access to the baseline of child content.
> Thanks very much for your consideration.
> Ron Ausbrooks on behalf of the Math Working Group
Received on Wednesday, 3 January 2007 18:57:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:22 UTC