Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=z3kzQaSb/fszkXNpJtbSurdXHJlzgT71ZCgA91xr6VxSzwqr8x3zjB4JuqF+Eho9fZQBU+RpWCY3n95wfc9uelgnUjCG/XMxgSUtXYhRnrFxYQCv4QMwZrZXrT7yyFZjzQOUOmeL8tlTeGF3cH3VMUJgoUlnLM0of2A2QJYO6z0=  ;
Message-ID: <20050404081102.98750.qmail@web50406.mail.yahoo.com>
Date: Mon, 4 Apr 2005 01:11:02 -0700 (PDT)
From: Andrew Girow <andrewgirow@yahoo.com>
Subject: Re: [SVGT12 Comment] Comments from Andrew Girow
To: Chris Lilley <chris@w3.org>
CC: www-svg@w3.org
In-Reply-To: <1378016775.20050402052701@w3.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Received-SPF: none (bart.w3.org: domain of andrewgirow@yahoo.com does not designate permitted sender hosts)

Hello Chris,

Thank you for your answers. 

Still I dont feel comfortable with the Color Traits
and I think it is a design problem.

Thanks again,
Andrew Girow
http://www.tinyline.com


--- Chris Lilley <chris@w3.org> wrote:

> On Wednesday, September 1, 2004, 5:31:03 PM, Andrew
> Girow wrote:
> 
> AG> From: andrewgirow <andrewgirow@yahoo.com>
> AG> To: SVG-Mobile@yahoogroups.com
> AG> Date: Wednesday, September 1, 2004, 5:00:04 PM
> AG> Subject: [SVG-Mobile] SVG Tiny 1.2 DOM Feedback
> and Questions
> 
> AG> While checking/ implementing SVG Tiny 1.2 DOM
> AG>  I got several questions:
> 
> Hello Andrew,
> 
> The SVG Working Group thanks you for your review of
> the SVG Tiny 1.2 
> Last Call specification draft. The group has
> reviewed you comments and 
> has the following responses.
> 
> AG> 1. THE COLOR TRAITS
> AG> In the A.2.6 Attribute and Property Access is
> written "Trait is the
> AG> typed value (e.g., a number, not just a string)
> that gets assigned
> AG> through an XML attribute"
> 
> AG> The set trait for color uses two functions
> instead of one:
> 
> AG> setRGBColorTrait [null | SVGRGBColor]
> AG> setTrait(none | currentColor | inherit)
> 
> AG> I see here a problem for application programmers
> who are not experts
> AG> in SVG. Why there are two functions for the same
> type?
> 
> AG> The get trait for color uses just one function:
> getRGBColorTrait.
> AG> So, there is no way to know that the given
> PathElement, for example,
> AG> uses the `currentColor' of the parent
> GroupElement.
> 
> AG> The get trait also does not allow to know that
> the PathElement fill
> AG> attribute is inherited from the parent
> GroupElement.
> 
> AG> If the getRGBColorTrait returns null. What it is
> suppose to mean:
> AG> none, currentColor or inherit?
> 
> AG> The set and get traits must be consistent. If
> the program sets the
> AG> fill attribute to `currentColor' it must be a
> way later on to check
> AG> if this attribute equals to the `currentColor'.
> AG> As I understand the whole idea behind traits is
> to provide strongly
> AG> typed access to SVG attributes. In a case of
> color we have two types
> AG> instead of one!
> 
> 1. The Color Traits.
> 
> The group has carefully considered different
> alternatives to get and set 
> trait values and feels that the solution it selected
> (use of typed 
> methods for reading and writing trait values) is the
> best trade-off 
> considering the constraints. This is reflected in
> the latest work done 
> on the uDOM specification and the SVG 1.2 Full
> Working Draft that was 
> referenced from the SVG Tiny 1.2 specification that
> you reviewed did not 
> reflect these latest changes.
> 
> With the latest changes, typed methods are used to
> set values of a 
> specific type. So, for example, if the user wants to
> set a blue color on 
> an element, it will use the setRGBColorTrait method
> with an SVGRGBColor 
> value parameter. Null values are _always_ disallowed
> as trait values. If 
> special values are needed (such as 'none', 'inherit'
> or 'currentColor'), 
> the values are considered to be string values and
> set through the 
> setTrait() method.
> 
> When reading a trait, the user gets the _computed_
> value. In the case of 
> a color, the returned value is an SVGRGBColor
> instance or null in case 
> the computed value is 'none'. The SVG WG realizes
> the handling of 'none' 
> is asymetrical but the various options were
> considered (like allowing 
> null in setRGBColor or throwing an exception in
> getRGBColor if the value 
> was none) and the group feels the current design is
> the most natural for 
> developers which can do common operations on colors
> without much 
> specific knowledge of SVG.
> 
> 
> AG> 2. SVGSVGElement
> 
> AG> In the SVGSVGElement there is a new attribute
> that could not be found
> AG> in the previous versions of SVG DOM.
> 
> AG> attribute float currentRotate; // raises
> (DOMException) on setting
> 
> AG> The question is how this parameter applied to
> the current
> AG> transformation matrix?
> AG> Does it go after the currentTranslate of before?
> What are the order
> AG> of operations now for the current transform? Do
> we need this at all?
> AG> I mean that there is no explanation why it is in
> the DOM now.
> 
> 2. SVGSVGElement.
> 
> The documentation on currentRotate has been updated
> to precisely define 
> what it means and its relation with the currentScale
> and 
> currentTranslate members. The latest documentation
> says:
> 
> 
>         User Agent Transforms
> 
> The DOM attributes currentScale, currentRotate and
> currentTranslate are 
> combined to form user agent transformation which is
> applied at the 
> outermost level on the SVG document (i.e., outside
> the outermost 'svg' 
> element) if "magnification" is enabled (i.e.,
> zoomAndPan attribute is 
> set to "magnify"). Their values can potentialy be
> modified through 
> user-agent specific UI. User agent transformation
> can be obtained by 
> multiplying matrix
> 
>  [currentScale      0       currentTranslate.x]     
>    [cos(currentRotate) -sin(currentRotate 0]
>  [     0      currentScale  currentTranslate.y]  by 
>    [sin(currentRotate) cos(currentRotate) 0]
>  [     0            0               1         ]     
>    [         0                  0         1]
>  
> 
> i.e. (translate, then scale, then rotate the
> coordinate system). The 
> reference point for scale and rotate operations is
> the origin (0, 0).
> 
> Please let us know if you do not find these answers
> satisfactory.
> 
> 
> -- 
>  Chris Lilley                    mailto:chris@w3.org
>  Chair, W3C SVG Working Group
>  W3C Graphics Activity Lead
> 
> 


__________________________________ 
Do you Yahoo!? 
Yahoo! Personals - Better first dates. More second dates. 
http://personals.yahoo.com