- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Sat, 22 Dec 2007 16:46:22 +0200
- To: White Lynx <whitelynx@operamail.com>
- Cc: www-math@w3.org
On Dec 19, 2007, at 12:11, White Lynx wrote: >> movablelimits="false" and >> movablelimits=" false " are not treated in the same way. > > It's a general problem with XML attribute value normalization, if > non-validating parser does not read external DTD it can not > determine attribute type and treats it as CDATA. And in this day and age, XML vocabularies should be designed to be DTDless or, at minimum, to work when a DTD isn't processed. >> It follows that robustness authors are best off always omitting >> extra whitespace in attribute values. I suggest this be required >> for document conformance for this reason. > > It is good practice not to rely on parser to strip leading/trailing > spaces, but I would say this is general issue with XML attributes > (thus better to be addressed by XML Core WG), not something that > MathML WG should interfere with. This is not something that XML Core WG can solve. The XML layer gives attribute values as strings to a higher processing layer without knowing what the higher layer wants to do with them. The spec for MathML needs to define what a MathML renderer reading the DOM is to do with an attribute value like " false ". Now, the MathML spec can continue to say that you first trim whitespace and then compare against an internal constant. However, this evidently isn't currently implemented in Gecko (at least for this attribute) and experience with not only MathML but SVG and HTML as well suggests that if you spec the whitespace trimming approach, someone always implements the comparison without the trimming. Therefore, I suggests that regardless of what MathML defines as the UA processing model, document conformance should require the token to appear without surrounding whitespace so that conforming documents end up being resilient to implementation differences in whitespace trimming. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Saturday, 22 December 2007 14:46:41 UTC