RE: Request For Feedback: Traits

Thanks, Mike.

I am not an implementor, I am a web developer who has had a little
experience developing with SVG 1.1.  Can I ask the SVG WG or others who may
know the answer why the SVG 1.1 DOM was not brought into SVGT 1.2?  Will the
SVG 1.1-style DOM be brought into SVG Full 1.2?  Given that the SVG 1.1 DOM
provided strong typing, access to individual components and avoided string
parsing why was the new Trait mechanism developed?

Why is

a)  someCirc.cx.baseVal.value += 5.4;

better than

b)  someCirc.setFloatTrait("cx", someCirc.getFloatTrait("cx") + 5.4);

In the uDOM version (b), it seems that the scripting engine would first have
to parse the code to determine that I want to set/get a float trait, then it
would have to do a lookup of the trait itself (i.e. a two-step lookup since
the attribute name could be in a string variable instead of hard-coded as
"cx") while the SVG 1.1 DOM approach (a) can parse the code directly and
know that I need to set/get the cx attribute on the someCirc element.  It
seems that the first approach could be much faster because it can be
determined at "parse-time" versus at "run-time".

As a developer, I can appreciate both versions.  The uDOM provides the trait
methods that are common across all elements while the cx attribute is only
common for the elements of type SVGCircleElement, it's like virtual function
calls in C++ vs static function calls.  It provides abstraction in my code
if I want it.  However, as a web developer, I generally prefer the first
version because it's easier to type, easier to read, and I assume it will
execute faster (could be a naive assumption).

Thanks,
Jeff

Michael Ingrassia wrote:
> Hello,
>
>The opinion of those of us doing SVG implementation within Nokia is that
>we would like to see the trait accessor methods stay the way they are.
>We see the current approach having many benefits over a string-only
>approach.
>
>We agree with Doug's points and see the primary benefits as:
>
>1) The current trait methods API provides a means for strong typing
>(even in weakly-typed languages).
>
>2) It provides the ability to access and set the value of an attribute,
>and to access individual components of microsyntaces such as the numbers
>in rgb(0,0,0) and the path segments in a 'path' element's 'd' attribute.
>
>3) Having these methods is more efficient than having to parse string
>values each time an accessor or mutator is called.  On a mobile
>environment this is very critical for performance.
>
>4) This mechanism is not just useful for Java but even native
>implementations.  In our case we tend to use the same underlying engine
>for SVG support in many environments (C++, Java, EcmaScript, etc).
>
>Regards,
>Mike