Re: MathML DOM inconsistency - set/insertArgument

Hi, Mark,
Apologies for my delay in seeing and responding to this. We've now
incorporated a fix for what I think you may mean in the errata.
>>The set/insertArgument methods in the MathMLContentToken interface have
signature (int, Node) while in MathMLContainer the signature is
(MathMLElement, int). 
It depends on which inconsistency you mean. The fact that the int argument
is first in one case and second in the other should be repaired, but is
probably not serious enough to have caused your message. If that is your
concern, you may stop reading now, as you're entirely correct.

But the other difference in signature here - between a Node argument and a
MathMLElement one - is quite intentional. The MathMLContentToken is allowed
to have as CHILDREN Nodes which are either MathMLPresentationElements, Text
nodes (as in the core DOM Text interface), or Node(s) (hopefully not
plural!) representing the <sep> element; instances of the MathMLContainer
interface are presumed to have only strict MathMLElement nodes as children.
Manipulation of the child nodes in this sense can be managed via the
underlying core DOM functionality (Node::insertBefore or Node::appendChild);
note that the MathMLPresentationToken interface relies solely on the
underlying functionality and provides no additional insertion methods.

The point of the set/insertArgument methods is to get at the actual
ARGUMENTS of the MathML elements. Thus, in the MathMLContentToken case, it
skips over the <sep> elements; in the MathMLContainer interface, it skips
over "elements representing bound variables, conditions, separators,
degrees, or upper or lower limits".

The upshot of all this is that the Nodes which can legally be inserted as
arguments of the two interfaces are not quite the same - a MathMLContainer
interface's arguments must all be MathMLElements, while a
MathMLContentToken's may include Text nodes. It was felt to be wise to
codify this distinction at the interface level rather than leaving it to
implementors to dig it out of the text of the recommendation.

The only other possible change we could make would be to change the name of
one of the methods. After a bit of head-scratching, and given that the
interfaces involved don't inherit from each other, I felt that that might be
more confusing than helpful. (Of course, that may not be correct.....)

I'm very interested in any other comments you may have about the MathML DOM
resulting from your implementation experience.

Received on Thursday, 23 May 2002 20:54:55 UTC