RE: Math WG comments on latest CDF documents

To be more specific on how this is being tracked:

Since this was originally marked as a disagree from the
first LC and then 
it was reraised during our second LC, we are not tracking it
as 2 
disagrees.  Only the one [1] against the first LC for
comments.

Thanks,
Steve Speicher

[1] See LC1-104 in 
http://www.w3.org/2004/CDF/2006/LC_Comments/CDRFWICDLC
.xml

I wrote on 01/03/2007 01:58:07 PM:

> 
> Ron,
> 
> 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.ausbrooksmackichan.com> wrote on 11/14/2006 
01:34:33 
> AM:
> 
> > 
> > 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 
> child
> > document by reference (via an <object>), and
we don't feel that the 
> current
> > 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 
> general
> > compound document framework. Some brief discussion
of layout 
negotiation 
> for
> > objects which are not scalable should appear in
the WICD Core 
document, 
> or
> > perhaps even in the Document Object Model section
of the CDR Framework
> > document.
> > 
> > Our specific suggestion is to include a
specification like the 
> following:
> >   "The Document Object Model for a child
document SHOULD make 
available 
> to
> > 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 
> supported
> > already by some user agents, and has allowed
scripting to provide 
> reasonable
> > 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 
> profile
> > is the best course, as we don't believe they apply
only to MathML. Any 

> child
> > 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 
> these
> > 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 
> for
> > MathML and examples of MathML from them for now,
as in our opinion 
these 
> are
> > currently misleading. In particular, the section
delineating the scope 

> of
> > 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 
> explicitly
> > state that automatic size negotiation between
parent and child is not
> > currently supported by CDR but will be addressed
in CDI; this 
> negotiation
> > 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
> > 
> > 
> > 
> 
> 

On Thursday, March 29, 2007, 11:28:25 PM, David wrote:


DC> Steve

>> To be more specific on how this is being tracked:
>> 
>> Since this was originally marked as a disagree from
the first LC and then 
>> it was reraised during our second LC, we are not
tracking it as 2 
>> disagrees.  Only the one [1] against the first LC
for comments.

DC> As a personal response, I don't think that this is
sufficiently clear
DC> logging of the status. The current situation makes it
look as if the
DC> original comment which was essentially re-raised has
now been agreed to
DC> be non-applicable which certainly is NOT the case.
Marking it as "disagree"
DC> would be clearest, or as an absolute minimum marking
it as duplicate of
DC> the earlier comment would be just about acceptable. 
Either way it
DC> should be coloured red not green in the last call
document disposition
DC> of comments document. Being a duplicate comment
(which it wasn't,
DC> exactly) is not the same as being "not
applicable".

I think that explicitly marking it as a duplicate is the
best way
forward. That would avoid the 'double count' concern that
Steve
mentioned. And it should be coloured red because it has the
same
status as the comment it closely duplicates.

I agree that 'not applicable' is not an obvious way to mark
a
duplicate.




-- 
 Chris Lilley                    mailto:chrisw3.org
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG