RE: [SVGMobile12] uDOM attribute normalization and getAttribute

Bjoern,
It sounds like you are trying to achieve a world where setAttribute('width', '45.57') followed by getAttribute('width') [or getFloatTrait or CSS OM methods) will always result in the same value no matter what DOM APIs are used, no matter what the object is, and no matter which user agent is used.

No, that's not what normalization means in this context. It isn't forcing a particular reproducible result; in fact, it is going in the other direction. It is allowing a user agent to normalize according to its own requirements, and thereby possibly changing the value. For example, '45.57' via a setter might come back as '45.6' or '45.5698' via a getter.

If you need to write script that compares two values, you as the script writer have to understand that the normalization option allows for the value to change both on the way in (i.e., the setter) and on the way out (i.e., the getter). One thing I will point out is that most scripts that I have seen do not leverage values stored within the SVG DOM for comparison purposes. Most comparison logic is at a higher abstraction level which deals with semantically meaningful objects, either stored as custom namespace DOM objects (which uses Core DOM only, which operates only on strings) or ECMAScript objects (which doesn't involve DOM).

Jon

-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of Bjoern Hoehrmann
Sent: Thursday, January 19, 2006 2:21 PM
To: Robin Berjon
Cc: www-svg@w3.org
Subject: Re: [SVGMobile12] uDOM attribute normalization and getAttribute


* Robin Berjon wrote:
>You make an interesting argument. However it lacks references for its  
>axioms. Pointers and their accompanied commentary would definitely  
>help assess whether:
>
>  a) the DOM spec is buggy compared to what was convened with other  
>WGs, notably but not solely the SVG WG
>  b) the DOM spec might not be what those WGs wanted, but cannot be  
>fixed and therefore the fix lies on those WGs' side
>  c) adding a mention to the uDOM indicating that the DOM parsing is  
>expected to operate as if 'datatype-normalization" were set to true  
>would address your concerns (this was considered at some point but  
>few people saw value in it)
>  d) the strawman reconciliation concerning the traits that I sent a  
>few days back is workable for you (and perhaps others, as Anne has  
>indicated)
>  e) you're simply wrong (hey, I'm listing *all* options ;)

I want the following to hold true:

  * for attributes and attribute values common to SVG Tiny 1.2 and SVG
    "Full" 1.2 there is no difference between what constitutes two
    equivalent attribute values;

  * implementations are not required to expose the difference between
    two syntactically different attribute values only if the
    specifications define that the two values are equivalent;

  * equivalence of attribute values does not depend on contextual
    information

  * equivalence of presentation attribute values is consistent with
    equivalence of CSS property values

And I think we should rather talk about how anything else might be
desirable than what might be permissable under some interpretation of
vague and incomplete suggestions in DOM Level 3 Core. Regarding d) I'm
all for dropping this ingenious "TraitAccess" interface. What you pro-
pose in terms of canonicalization is tricky to get right but would make
sense regardless of "TraitAccess" interfaces. Whether this would make
the best possible interface to the SVG DOM in SVG Tiny 1.2 is not clear
to me, but that's out of scope here.
-- 
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 22:40:44 UTC