- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 7 Jan 2008 15:40:07 +0200
- To: Paul Libbrecht <paul@activemath.org>
- Cc: Public MathML mailing list <www-math@w3.org>
On Dec 22, 2007, at 21:21, Paul Libbrecht wrote: > Le 22 déc. 07 à 15:31, Henri Sivonen a écrit : >>> Applications emitting MathML should, when outputting the encoding >>> attribute of the annotation or annotation-xml children of the >>> semantics element, either: >>> 1- use one of the names listed in this spec, if applicable >>> 2- use a mime-type if one exists for the data >>> 3- use a namespace URI if this URI is the namespace URI of the >>> single root child of an annotation-xml that is being output >>> 4- use an self-decided character string >>> >>> Note that the encoding attribute value of case 4 does not impact >>> the XML parsing architecture which still needs appropriate xmlns >>> declarations. >> >> I think that formulation is still problematic. >> >> For annotation-xml, it doesn't explain what value the encoding >> attribute provides over the namespace of the child element. > > It cannot because 1 and 2 are still applicable. 1 and 2 are applicable only because they are in the spec. I'm talking about what the spec should say. A user agent gets a MathML tree (possibly subtree inside XHTML). The MathML tree contains an annotation-xml elements whose only child is an element in the SVG namespace. The encoding attribute on the annotation- xml element has garbage in it. Let's assume that the UA can render SVG in annotation-xml (like, e.g. Gecko can). Why would the UA ever be better off letting the encoding attribute be authoritative and ignoring the annotation-xml element and its contents as opposed to always ignoring the encoding attribute and checking if the child of the annotation-xml element is in a namespace that the UA knows about? >> Wouldn't it be better to suggest that legacy generators continue to >> be allowed to use an encoding attribute on annotation-xml but it >> must be ignored by consuming apps and the namespace of the child >> must be used for dispatching instead (and suggest that new >> generators omit the attribute)? > > It is just a commodity feature. Sorry, I don't understand what you mean by "commodity feature" and I don't understand how the encoding attribute being a commodity feature answers the question. > You certainly don't want to ignore an encoding attribute if with 1 > and 2. Or? If I'm a UA that supports SVG in annotation-xml, sure, I'd always want to ignore the encoding attribute and check if encoding-xml contains an element 'svg' in the SVG namespace. Likewise, if I'm a UA that support OpenMath in annotation-xml, I'd want to ignore the encoding attribute and examine if the child of annotation-xml is in the OpenMath namespace. Same for XHTML. > Maybe we need more examples? No, I think the spec needs a more precise normative processing model that is compatible with the processing model of deployed MathML- consuming apps. Leaving it to the reader to infer the processing model or authoring requirements from examples is a bad idea, in my opinion, and is exactly what has happened with MathML 2.0. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Monday, 7 January 2008 13:40:31 UTC