Re: [1.2T-LC] 16.2.9 by 'identity' (ISSUE-2093, ACTION-2319)

Hi Doug,
> Hi, Dr. Olaf-
>
> Dr. Olaf Hoffmann wrote (on 10/1/08 10:07 AM):
> > in 16.2.9 it is mentioned:
> >
> > ##
> > If a 'by' value is used on a non-scalar data type ( such as color or
> > transform ), the starting 0 delta value is to be conceptually
> > considered as 'identity'.
> > ##
> >
> > If this is to be interpreted within some algebraic relation, it is
> > required to define or to specify the binary operation a value is
> > considered the 'identity' for. Luckily already in SMIL is defined, that
> > this type of animation is only available, if additive animation is
> > supported. The SMIL 3 CR already explains in more detail, that the
> > starting '0' is "the neutral element for addition for the domain of the
> > target attribute". Therefore the binary operation must be the addition
> > (even or especially because not explictly mentioned), this means if X is
> > a value, then X + 'identity' = X, with '+' beeing an additive operation
> > for the space X belongs to.
> > For example for RGB-colors this means the 'identity' is black, #000,
> > rgb(0,0,0) etc;
> > for vector like types this is the origin (zero length, any direction);
> > for lists of numbers (lengths etc) it might be a list of zeros
> > - right?
>
> Yes, that is the idea.
>
> In our offlist exchange, you seemed to indicate that this is already
> clarified in SMIL3.  

Yes, but the wording in SMIL3 is more complete/meaningful than
it is in SVGT1.2 (well, it is basically based on my wording due to a 
comment about a SMIL3 draft, therefore it is obviously more 
meaningful to me ;o)

With the current sentence in SVGT1.2 it provokes such questions
as above - is it the same or not, 'identity' related to what?

From my point of view it would be more consistent, to adopt the
wording from SMIL3 for SVGT1.2 (and maybe to skip it for later
SVG versions referencing SMIL3 already). This ensures better
(forward) compatibility already in SVGT1.2.

Therefore my suggestion is to adopt it from SMIL3:

"A <em>by animation</em> with a by value <code>v<sub>b</sub></code> 
is equivalent to the same animation with a values list with 2 values, 
the neutral element for addition for the domain of the target 
attribute (denoted <code>0</code>) and <code>v<sub>b</sub></code>, 
and additive<code>=</code>"sum". 
Any other specification of the additive attribute in a <em>by animation</em> 
is ignored."

If it is believed, that there are more doubts about this issue, one may
add samples:
"For example the neutral element for addition for the color domain 
is black, rgb(0%,0%,0%) or #000; the neutral element for the transform
types translate or scale is 0,0; the neutral element for the transform
type rotate is 0,0,0."
At least for me these samples are not required to be added,
there are tests in the test suite to prove the equivalence systematically
for several situations.


> Is there any need for a change in SVG 1.2 Tiny, in 
> that case?  

What could be added is some error handling, what is not
really mentioned in SMIL3. For by animations is only mentioned:
"This may only be used with attributes that support additive 
animation."
This sounds more like a warning for authors, never to try it, 
because no one knows, what might happen if it is tried.
Because the SVGT1.2 style is more to know what happens,
even if authors note something nasty/stupid, one can say that 
"by animations for non additive  attribute values as mentioned 
in 16.2.18 (...) have no effect."

But I do not want to foist this to the WG for SVGT1.2, this needs 
discussion/agreement/research/work from the group, especially 
because there are several attributes, in particular 'list of XXX' 
defined to be none additive (presumably for other than just 
technical reasons or for reasons not directly related to this issue).

Alternatively one may write:
'Because by animations are always additive, by animations do
not apply to none additive attributes. If this appears anyway, 
the behaviour is currently unspecified in SVGT1.2 and can have 
different effects in different viewers.'




> If there is a contradiction, 

It is more, that the current sentence does not provide more information
as if it is skipped at all, but it creates not very interesting questions or
uncertainness for the reader.

> we will certainly look at  
> changing it, so please give us the details.

see above.

Olaf

Received on Saturday, 18 October 2008 14:55:37 UTC