W3C home > Mailing lists > Public > www-validator-cvs@w3.org > March 2014

[Bug 25104] The RelaxNG schema should recognize more encoding values for the <annotation-xml> element

From: <bugzilla@jessica.w3.org>
Date: Fri, 21 Mar 2014 09:36:33 +0000
To: www-validator-cvs@w3.org
Message-ID: <bug-25104-169-9Bv2UBQdDu@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25104

--- Comment #7 from David Carlisle <davidc@nag.co.uk> ---
If I'd ruled the world things would have been different:-)

The situation is that in the core MathML RelaxNG schema annotation-xml allows
arbitrary content and the encoding attribute takes arbitrary values.

attribute encoding {xsd:string}?

In application/xhtml+xml parsing there is an argument that says that this
should be as above, however I think there is also the argument that the
HTML+MathML+SVG schema should try to steer people towards HTML/XHTML
compatibility by default.

In text/html parsing things are as usual rather more murky.

annotation-xml doesn't really take arbitrary content it's either parsed as html
(encoding=text/html or application/xhtml+xml) or as MathML (any other
encoding).
Namespaces in the content are as usual mangled/ignored.


This means for example that if you want to put SVG in the annotation-xml you
need to use encoding application/xhtml+xml because then the html parser sees
<svg> and automatically puts things back in foreign content in svg namespace
and things work. If you put any SVG-related value for the encoding the elements
will be parsed as unknown elements in the MathML namespace. 

So... In an ideal world I'd make the HTML parsing more sensible, but until or
unless there is a proposal to make things work in HTML parsing I wouldn't say
that the validator is wrong to warn about any encoding other than the HTML or
MathML ones. That doesn't mean that the browsers shouldn't accept whatever
makes sense of course.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Friday, 21 March 2014 09:36:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:17:56 UTC