W3C home > Mailing lists > Public > www-math@w3.org > December 2007

Re: Whitespace around enumerated attribute values

From: Henri Sivonen <hsivonen@iki.fi>
Date: Sat, 22 Dec 2007 16:46:22 +0200
Cc: www-math@w3.org
Message-Id: <EFCB8769-05B4-4E9F-9D86-D570FF12DCE7@iki.fi>
To: White Lynx <whitelynx@operamail.com>

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
Received on Saturday, 22 December 2007 14:46:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:27:39 UTC