Re: annotation-xml and annotation encoding

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

Received on Monday, 7 January 2008 13:40:31 UTC