Re: [SVGMobile12] uDOM attribute normalization and getAttribute

* Anne van Kesteren wrote:
>> """
>> The way attribute value normalization is performed by the DOM  
>> implementation depends on how much the implementation knows about the 
>>  schema in use. Typically, the value and nodeValue attributes of an  
>> Attr node initially returns the normalized value given by the parser. 

>It only talks about modified attribute values (in one way or another). 
>The same is true for the "style" attribute in (X)HTML documents which
>will after being modified give 'unexpected' results when you do a
>getAttribute on it. Initially though it represents what is being set.
>And I have either misread the above quote or implementations are not
>allowed to return a modified (normalized) attribute value when it is
>not modified.

You've missed a key part. The intent is that DOM implementations are not
required to expose to preserve lexical differences between equivalent
values. When two values are equivalent is defined by specifications like
SVG Tiny 1.2. DOM Level 3 Core however does not license what SVG Tiny
1.2 actually does; the draft rather assumes that the DOM allows for
arbitrary computations and transformations which show little or no re-
semblance of the actual values.

If you think of this normalization in terms of a map f(x) where x is the
string value you are trying to normalize, then there is no such f that f
maps a relative resource identifier to an absolute one. Yet this is a
legal "normalization" per SVG Tiny 1.2. For the 'display' presentation
attribute you can devise such a function, but there is no specification
that defines "block" to be equivalent to "inline", yet this is another
allowed normalization.

Where things become a little bit more difficult is e.g. "normalization"
of paths and matrices. SVG 1.1 requires implementations to expose the
difference between relative and absolute path commands and individual
transforms in a transformation list; SVG Tiny 1.2 allows implementations
not to do that. For that to be consistent with DOM Level 3 Core there
would need to be specific language in the draft that says there is no
difference whatsoever between these lexical representations. If there
is such text in the draft, it would contradict SVG 1.1.

So, as you point out in your original message, SVG Tiny 1.2 is indeed in
conflict with DOM Level 3 Core and I would recommend to register formal
objection to the Working Group's response. It's technically incorrect.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Thursday, 19 January 2006 17:50:02 UTC