Hello everybody,
about the current changes in the editors draft concerning
by animations:
Now there is a table added with some content even more
confusing than the previous wording. In one case this
is even misleading of wrong.
1. Because in the table of section 16.2.18 it is noted,
that attribute and property types not explictly mentioned
in the table are not additive, expecially list-of-XXX,
path-data and points-data are not additive.
by animation is defined to be always additive.
Therefore it is pretty irrelevant, what in a by animation
for such type the 0 might be, because currently
a by animation is not defined for them at all.
SMIL notes about this (as already mentioned in the
previous response):
"A by animation with a by value vb is equivalent to the same animation
with a values list with 2 values, 0 and vb, and additive="sum". Any other
specification of the additive attribute in a by animation is ignored."
or the better wording from SMIL3 PR:
"Normative: A by animation with a by value vb 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 0) and vb, and
additive="sum". Any other specification of the additive attribute in a by
animation is ignored."
http://www.w3.org/TR/SMIL3/smil-animation.html#q34
Therefore it does not help to define what 0 is, because the complete animation
has no meaning, maybe only some error management can be defined for such
by animations of non additive types, if it is required to have a defined
behaviour.
2. Note, that SMIL defines the equivalence to a values animation, not to
a from-to animation. This is not really a difference, because SMIL defines
too the from-to animation to be equivalent to a values animation, but
I cannot see any reason, why to confuse readers with a different wording
and a more complicated rule-chain for this.
3. The 0 for color is identified correctly and has a meaning, this is ok.
4. The wording for transform is misleading or wrong.
Especially the SMIL animation animates between the values lists and
no matrices. To animate between the resulting transform matrices
would result in a different effect, especially for skewing and rotation.
And up to now, the matrix type is unfortunately not animatable
in SVGT1.2 for whatever reason. Therefore for transform we have
either a list of one, two or three numbers as values. SMIL animation
does not care about what they represent (except from the distance
definition for calcMode paced). Even if we interprete any scalar or
vector as a matrix (what is possible and no further problem),
the operation we are looking for for SMIL animation is still addition and
nothing else. Therefore we are always looking for the neutral element
of addition, the identity function of addition, the identity transformation
concerning addition etc.
To get the right object, one can use a simple test. If N is a candidate
for such an identity and E is an arbitrary element from the space we
are looking on, then N has to fulfill the following condition:
N + E = E + N = E (assuming that the left and right identities are the
same for our problem).
Additionally we can look at wikipedia to see, what other people get
for common constructions:
http://en.wikipedia.org/wiki/Identity_element
What we find for all we need, scalars, vectors, number lists, matrices
ist the neutral element for addition, what is called 0, or in expanded
beautiness:
http://en.wikipedia.org/wiki/Zero_matrix
This is all we need to identify what exactly 0 is, not more.
The typical usage of the word 'identity matrix' mentioned in the
current wording is not related to 0 or the zero matrix, zero vector,
list of zeros, it is related to the so called unit matrix, Einheitsmatrix,
related to the symbol '1':
http://en.wikipedia.org/wiki/Identity_matrix
One can clearly see that 1 is not the neutral element of addition:
1 + E is not equal to E for no E at all.
Therefore the wording 'identity matrix' is obviously wrong.
Especially for the transform type scale this results in a wrong
animation effect, this can be simply seen, if we look on the
section of cumulative animations in SMIL:
http://www.w3.org/TR/2005/REC-SMIL2-20051213/animation.html#animationNS-Accumulate
"To avoid jumps, authors will typically choose animation functions which start
at 0."
If a cumulative by animation starts with 1 instead of 0, this will create
unintended jumps not related to a by animation. This is just another
indication, that 0 is not 1 in SMIL animation too and results in nonsense.
To resume: To fix all this, the table and the sentence before
should be removed.
It is relatively simple to identify what 0 is in the future, when
the next version of SVG refers to SMIL3. Alternatively one can
simply look into resources like wikipedia ;o)
The correct behaviour for animateColor and animateTransform
is already tested in the test suite, wrong implementations will not
pass this anyway.
If the working group wants to do something useful about by animations,
there could be a definition of some kind of error handling, if a by
animations is accidentally used for a non additive type.
Even if such a definition is not provided, this causes not problem,
then the behaviour is simply undefined as before.
Olaf