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

Hello Dr. Olaf.

(Another personal reply, not the consensus of the WG.)

Dr. Olaf Hoffmann:
> 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.

I don’t know why these are not additive.  That seems to have been in the
spec for quite a while, but I don’t know why this is the case.  Allowing
these to be additive doesn’t cause any conceptual problems in my mind,
and certainly no technical problem.  By my reckoning, all of the numeric
data types should be listed as additive:

  color
  coordinate
  font-size-value
  integer
  length
  list-of-coordinates
  list-of-lengths
  list-of-numbers
  long
  number
  paint
  path-data
  points-data
  transform

> …
> 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.

Of course.  I might argue that the actual fix should be to ensure
list-of-length etc. are additive.

> 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.

Indeed, this should say that it is defining the zero value for the
equivalent values animation.

> 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

I think transform animations are already a bit weird, because the
operation being performed for additive/cumulative animations is matrix
multiplication, not addition.  In that context, saying that the zero
value is the identity matrix seems appropriate.

> "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.

If addition of transform animations is treated as matrix multiplication
(which is what the spec says currently), I don’t think this problem
really exists.

> To resume: To fix all this, the table and the sentence before
> should be removed. 

Apart from the table in 16.2.18 not listing all of the additive types
properly, I don’t think there is a problem.

> 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)

Is it relatively simple to identify what 0 is now?  Well, yes, it’s not
too hard, but I would rather have it explicitly called out, especially
since we likely won’t be changing to normatively reference SMIL 3 at
this late stage.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 30 October 2008 02:34:42 UTC