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 12:33:17 UTC