RE: Request For Feedback: Traits

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


>>-----Original Message-----
>>From: ext Doug Schepers [mailto:doug.schepers@vectoreal.com]
>>Sent: Wednesday, January 04, 2006 12:14 AM
>>To: www-svg@w3.org
>>Subject: RE: Request For Feedback: Traits
>>
>>Hi, all-
>>
>>Just to clarify, all responses can be sent to www-svg@w3.org, the 
>>public discussion list for the SVG Specification. This is a 
>>subscriber-only list, so if you wish to reply and you are
>not yet on
>>the list, you should send an email to www-svg@w3.org with the word 
>>'subscribe' in the subject line.
>>
>>Regards-
>>Doug Schepers,
>>on behalf of the SVG Working Group
>>
>>doug.schepers@vectoreal.com
>>www.vectoreal.com ...for scalable solutions.
>> 
>>
>>Doug Schepers wrote:
>>| 
>>| Hi-
>>| 
>>| The SVG WG is interested in soliciting opinions,
>particularly from
>>| implementors, about the 'traits' feature of the SVG uDOM.
>>| 
>>| You can find a detailed description of the traits interface
>>throughout
>>| the current draft of the uDOM [1], and in specific in section
>>| A.7.12 TraitAccess
>>| [2].
>>| 
>>| The SVG WG feels that this interface addresses many
>author-requested
>>| needs, including the ability to access and set the animated or 
>>| computed 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]. It also provides strong typing, which is
>>useful even in
>>| weakly-typed languages like EcmaScript since it can distinguish 
>>| between booleans, strings, and numbers (a useful feature for
>>those who
>>| script SVG, since DOM methods only return strings), and
>>provides clear
>>| exception messages for erroneous trait values, allowing
>for ease in
>>| debugging. The SVG WG does not feel that it is a redundant
>>feature to
>>| DOM 3, but is rather complementary.
>>| 
>>| Any criticism (or praise) of the 'traits' feature is very
>>welcome. We
>>| are especially interested in whether you see value in
>providing this
>>| mechanism beyond the scope of Java, such as in EcmaScript, C#, or
>>| other languages. If there are particular features that
>you feel are
>>| inappropriate or that conflict with other specifications
>>(such as DOM
>>| 3), and which would prevent your adoption of 'traits', we
>encourage
>>| descriptions of those issues along with proposed resolutions.
>>| 
>>| [1] http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/svgudom.html
>>| [2]
>>| http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/svgudom.html
>>| #svg::TraitAcc
>>| ess
>>| [3]
>>| http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/svgudom.html
>>| #Attribute_Nor
>>| malization
>>| 
>>| Regards-
>>| Doug Schepers,
>>| on behalf of the SVG Working Group
>>| 
>>| doug.schepers@vectoreal.com
>>| www.vectoreal.com ...for scalable solutions.
>>| 
>>
>>

Received on Thursday, 12 January 2006 04:15:37 UTC