Comment from Math WG on CDF Last Calls

It has been pointed out to me that I wrongly did not send the Math WG
comments to the correct list, and that this could be the cause of
our comment not having been logged as we expected.  To help,
I therefore send to this list the W3C Math WG reply, which was
earlier addressed only to Steve Speicher and Kevin Kelly as chair

For the Math WG,

	Patrick Ion (Co-chair)


Steve K Speicher wrote:
> Thanks for the quick and thorough reply.  I have discussed these items
> with the CDF WG and have included our response inline.

Dear Steve,

Thanks in turn for a careful reply on your part.  Unfortunately,  
though the
Math WG is grateful for the small change that you are willing to add  
to the
CDRF document:

> "It is possible for a content author to use parent-to-child [link] or
> child-to-parent [link] to propogate specific styling properties."
{presumably with the typo fix ' propogate'  =>  'propagate'}

  I have been enjoined by the WG, after careful discussion, to make sure
that our comment LC2-132 on the Last Call be recorded as 'unsatisfied'
(or 'disagree') on the Disposition page

We do understand your formulation that in the WICD documents you
do not feel inclined to "outline what we don't support in other areas"
or "believe stating {the} future of futures drafts is appropriate in  
specifications".  We do think that, even though the first lines of the
WICD documents state up front their restricted scope
(XHTML + CSS + SVG) it is very likely that they will be understood,
together with the CDR Framework document, as addressing the much
larger problem areas that their titles imply.  For this reason we are  
of the
opinion that it is important to spell out what's still for the  
future, and
to clarify a possible misimpression, which a nice introduction  
more general compound documents as we'd all like to see them
seems to give.  We thought we had proposed a way to do this without
great difficulty.

The Math WG too will be pleased to work, with the CDF effort, on the
development of a more general Compound Document Format, that
is clearly needed at least for scientific and technical  
publications.  We
do note that the present CDF WG is only chartered until November 2007,
and worry that the pressure of finishing specs already in the works may
not leave much time to address some of the further issues we probably
all agree are still pending.   However, we reiterate our willingness to
help address whatever we can to aid in improving the Web through
the W3C.

On behalf of the W3C Math Working Group,

       With best regards,

>> Dear Kevin and Steve,
>> Thank you again for working with the Math WG to clarify the
>> matter of CDF where it touches on things involving MathML or
>> other text-like material.
>> As you know we were very worried that what is needed for dealing well
>> with MathML was apparently not covered, and at first had the  
>> impression
>> that it was expressly forbidden.  Now we understand better what you
>> set out to do with your first documents, and hope that the small  
>> amount
>> of clarification wording we offer will help others in  
>> understanding the
>> situation quicker.
>> I think we all agree that we'd like to be able to the Web able to  
>> handle
>> more complex Compound Documents, such as scientific and engineering
>> ones using XHTML, SVG and MathML, as your nice examples show.
>> We're also together in thinking that it is easier to implement
>> processsing
>> of  documents with actual inclusion of other XML vocabularies
>> than of those in CDR form.  We hope we will be able to work with the
>> CDF WG, where appropriate, in looking at CDI, or more specifically on
>> profiles including MathML.
>> Accordingly, for now, we’d propose the following three non-normative
>> additions to CDF 1.0:
>> 1.  In CDRF, at the end of Section 2.1 (just before Section 2.1.1
>> “Specialized DOM access”), the following paragraph currently appears:
>> Each child document DOM generates its own scripting execution
>> context. Each child DOM scripting execution context provides access
>> to its corresponding global object. The CSS style- sheet cascade is
>> applied to each DOM in isolation. CSS property inheritance is
>> inhibited at inclusion boundaries.
>> We propose to append the following paragraph:
>> Note: The description above is intended to reflect the current state
>> of affairs in most applications.  The inhibition of CSS property
>> inheritance is problematic for child documents which produce textual
>> or text-like content (e.g., MathML). In order to provide adequate
>> support for integration of such child document formats, it will be
>> necessary to reconsider this issue in some future version of the
>> Compound Document Framework.  As it stands today, Compound Documents
>> containing more than XHTML and SVG, such as MathML, are handled in
>> various ways using scripting  and non-standard access to the DOM to
>> exchange information between the handlers of child documents and the
>> root document.
> We agree that adding some informative statement would assist here.   
> We are
> proposing this:
> "It is possible for a content author to use parent-to-child [link] or
> child-to-parent [link] to propogate specific styling properties."
>> 2.
>> In WICD Core, at the end of Section 3.3.1, following the paragraph
>> beginning “When an embedded child document fragment (such as SVG)
>> specifies its horizontal width and omits a height…”, we propose
>> adding the following paragraph:
>> Note: The size and layout considerations above do not provide much
>> support for embedded child document fragments in formats which
>> produce in-line textual or text-like replaced content (e.g. MathML).
>> These child document formats require more communication and
>> negotiation between the child and parent documents, particularly the
>> ability to pass intrinsic size and baseline information back and
>> forth from the child to the parent. This should be addressed in
>> future versions of WICD designed to support such formats.
> We will not be making any changes based on this.  Since we don't  
> outline
> what we don't support in other areas, it could open us up to have to
> outline what we don't support for other markups and other areas as  
> well.
> Also, we do not believe stating future of futures drafts is  
> appropriate in
> these specifications.  As we have stated, we will work with the  
> Math WG on
> these items on our future versions.
>> 3.
>> Finally, in WICD Core at the end of Section 7.2 “Font Naming”,
>> following the paragraph beginning “In SVG, named fonts, or subsets of
>> fonts…”, we propose adding the following paragraph:
>> Note: Adequately rendering other markup languages, such as MathML,
>> may require additional font support. This must be addressed in a
>> future profile including such languages.
> We will not be making any changes based on this.  This is for the same
> reasons as #2 above.
>> Of course, the exact language might possibly be improved.  But some
>> explicit statement that CDF as it stands doesn’t provide sufficient
>> support for embedding formats such as MathML is what remains
>> important to us.
>> As we’ve said before, we hope to work with you in the future on a
>> profile to include MathML. Thank you very much for your attention to
>> our concerns.
>> On behalf of the Math Working Group,
>>       Patrick

Received on Thursday, 5 April 2007 13:25:09 UTC