Re: DOM WG comments on the MathML 2 Last Call

Thank you so much for your comments! We have been tracking the DOM IG so we
are already making fixes and preparing a response.

Angel


"Lauren Wood" <lauren@sqwest.bc.ca>@w3.org on 04/25/2000 12:31:46 PM

Please respond to lauren@sqwest.bc.ca

Sent by:  www-math-request@w3.org


To:   www-math@w3.org
cc:
Subject:  DOM WG comments on the MathML 2 Last Call



General comments:
- Why is the DOM API defined to be non-normative? We can understand
optional, but surely if anyone is implementing a MathML DOM, they should
use the one the MathML WG has defined.

- There is no IDL package deined for the interfaces. You also need to
define
a hasFeature string.

- You don't use DOM Level 2. Is there a reason for this?

Chapter 7:
"class, id, style
                Provided for style sheet and DOM compatibility."

What does "DOM compatibility" mean here? By "style sheet", do you mean
"cascading style sheet"?

Chapter 8:
"Various specializations of MathMLElement to encode syntactical
restrictions imposed by MathML."

Since the Core doesn't provide any syntactical restrictions, how are you
planning to enforce this statement? Some examples could be exceptions or
defining methods.

"Thus far (XML DOM level 2), issues such as privacy with regard to
user-side
style sheets have resulted in no core DOM methods being defined for
obtaining the cascaded, computed or actual style values for a specific
element, with DOM access being limited to providing the style declarations
which are in effect. If a future iteration of the XML DOM were to expand
this
access, the methods used there would apply to the MathML DOM as well,
and render any specifications we might make now obsolete."

The DOM Level 2 CSS module provides access to CSS documents, CSS
inline style declarations and computed CSS style. And there is no "XML
DOM Level 2" as such - what is meant by this? The Core module alone?

Appendix E:
Interface MathMLDOMImplementation:

interface MathMLDOMImplementation: DOMImplementation {
 MathMLmathElement createMathMLmathElement(in Document
hostDocument,
                                     in Node parent);
};

We use the Document interface to create an element so it should be

interface MathMLDocument: Document {
 MathMLmathElement createMathMLmathElement();
};

and this would make hostDocument no longer relevant.

We don't understand what the parent parameter is doing. Can't an Element
be created without the parent Node? What about consistency with the DOM
Level 1 createElement method?

Interface MathMLDocumentFragment:

interface MathMLDocumentFragment: MathMLElement {
};

A DocumentFragment is not an element. One question we have if you do
define it as being inherited from a MathMLElement is what do className,
style and id mean on a DocumentFragment?

Interface MathMLElement:

interface MathMLElement: Element {
 attribute DOMString className;
 attribute DOMString style;
 attribute DOMString id;
};

There is a conflict between this style attribute and the style attribute
used by
the CSS OM in DOM Level 2 [1]. You should rename this attribute to support
the ElementCSSInlineStyle interface.

Interface MathMLmathElement:

interface MathMLmathElement: MathMLElement {
 readonly attribute MathMLDocumentFragment declarations;
 attribute DOMString macros;
 attribute DOMString display;
 MathMLdeclareElement insertDeclaration(in MathMLdeclareElement
newDeclaration,
                                     in unsigned long index);
 MathMLdeclareElement setDeclaration(in MathMLdeclareElement
newDeclaration,
                                     in unsigned long index);
 MathMLdeclareElement removeDeclaration(in unsigned long index);
 MathMLDocumentFragment createMathMLDocumentFragment();
 MathMLElement createMathMLElement(in DOMString tagName);
};

declarations :
 Provides access to the declare elements which are children of this math
element

We don't understand how an element can be a child of an element and a
child of a document fragment at the same time.

Interface MathMLXMLAnnotationElement:

interface MathMLXMLAnnotationElement: MathMLElement {
                   readonly attribute NodeList contents;
                   attribute DOMString encoding;
                 };

Do you really need to have a contents attribute ? Why not use the
childNodes attribute?

Interface MathMLPresentationToken:

contents of type MathMLDocumentFragment, readonly
[...]
Should behave the same as the base class's Node::children attribute;
[...]

The DOM doesn't have a Node::children attribute in the Node
interface; it's called childNodes.


Lauren

Received on Tuesday, 25 April 2000 14:14:59 UTC