Re: [SMIL30 LC comment] 3.6.4 Simple animation functions ...

 Dear Dr. Olaf Hoffmann  ,

The SYMM Working Group has reviewed the comments you sent [1] on the Last
Call Working Draft [2] of the Synchronized Multimedia Integration Language
(SMIL 3.0) published on 13 Jul 2007. Thank you for having taken the time to
review the document and to send us comments!

The Working Group's response to your comment is included below.

Please review it carefully and let us know by email at www-smil@w3.org if
you agree with it or not before 02 nov 2007. In case of disagreement, you
are requested to provide a specific solution for or a path to a consensus
with the Working Group. If such a consensus cannot be achieved, you will
be given the opportunity to raise a formal objection which will then be
reviewed by the Director during the transition of this document to the
next stage in the W3C Recommendation Track.

Thanks,

For the SYMM Working Group,
Thierry Michel
W3C Staff Contact

 1. http://www.w3.org/mid/200708151045.27991.Dr.O.Hoffmann@gmx.de
 2. http://www.w3.org/TR/2007/WD-SMIL3-20070713/


=====

Your comment on 3.6.4 Simple animation functions specified by from, to and
by:
> Hello SMIL working group,
> 
> 
> some comments on
> 3.6.4 Simple animation functions specified by from, to and by
> 
> 
> 'by animation'
> 
> '... This may only be used with attributes that support additive 
> animation. ...'
> 
> -> What happens if a nasty author uses it anyway with non-additive
> attributes?
> Is in such a case simply the additive behaviour ignored, the animation
> is
> equivalent with a values animation using the two values '0' and vb and
> additive="replace"? Or is the complete animation ignored as nonsense?
> I suggest the first behaviour...
> 
> 
> 'Normative: 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.'
> 
> 
> -> A certain uncertainty came up for some people, what '0' means in
> this
> paragraph. Sure, for attribute values consisting of a simple number or
> integer
> this can be identified simply as the number zero, but for more complex
> values
> there seems to be a gap of imagination ;o)
> In SMIL this happens too for example for animateMotion, animateColor or
> an
> animation of an attribute like viewBox. Values of animateMotion have
> two
> components, animateColor has three color components and viewBox
> requires 
> four numbers, therefore '0' itself is not directly applicable but has
> to be
> replaced with a specific value related to the animated attribute.
> According to my opinion, '0' in this paragraph is not simply the number
> zero,
> it is just a generic symbol or a wild-card as vb is too. Therefore I
> interpreted '0' always as a wild-card for the neutral element of
> addition in
> the value space related to the animated attribute or property. Is this
> correct?
> -> If yes, I suggest to add something like this:
> 'Note, that '0' is used here as a generic symbol for the neutral
> element of
> addition for the value type of the animated attribute or property. For
> example
> for animateColor '0' is used here as a symbol to be replaced with black
> or
> #000 or rgb(0,0,0), for animateMotion this is a symbol to be replaced
> with 
> the value of the origin 0,0. Similar substitutions have to be done for
> any
> attribute value.'
> 
> 
> 
> ---
> 
> 'to animation
> This describes an animation in which the animation function is defined
> to
> start with the underlying value for the attribute, and finish with the
> value
> specified with the to attribute. Using this form, an author can
> describe an
> animation that will start with any current value for the attribute, and
> will
> end up at the desired to value. 
> 
> A normative definition of a to animation is given below in To
> animation'
> 
> -> missing a '.' at the end
> 
> -> Note that the reference still points to the informative box, not to
> the
> normative box, this is maybe a little bit confusing within a normative
> sections, because it it noted, that it references a normative
> definition.
> 
> 'A to animation of an attribute which supports addition is a kind of
> mix of
> additive and non-additive animation.'
> 
> -> Well, this is now indicated only as informative, this was not the
> case in
> SMIL2.
> My interpretation now is, that it is not important, if the attribute
> supports
> addition or not, one has to follow the normative formulars below
> anyway? 
> But then the sentence above can be shortend to avoid confusion:
> 
> -> 'A to animation of an attribute is a kind of mix of additive and
> non-additive animation.'


Working Group Resolution:
> Hello SMIL working group,
> 
> 
> some comments on
> 3.6.4 Simple animation functions specified by from, to and by
> 
> 
> 'by animation'
> 
> '... This may only be used with attributes that support additive 
> animation. ...'
> 
> -> What happens if a nasty author uses it anyway with non-additive
attributes?
> Is in such a case simply the additive behaviour ignored, the animation
is
> equivalent with a values animation using the two values '0' and vb and
> additive="replace"? Or is the complete animation ignored as nonsense?
> I suggest the first behaviour...

The attribute is ignored.  The definition of the by attribute was changed
accordingly.

> 'Normative: 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.'
> 
> 
> -> A certain uncertainty came up for some people, what '0' means in
this
> paragraph. Sure, for attribute values consisting of a simple number or
integer
> this can be identified simply as the number zero, but for more complex
values
> there seems to be a gap of imagination ;o)
> In SMIL this happens too for example for animateMotion, animateColor or
an
> animation of an attribute like viewBox. Values of animateMotion have
two
> components, animateColor has three color components and viewBox requires

> four numbers, therefore '0' itself is not directly applicable but has to
be
> replaced with a specific value related to the animated attribute.
> According to my opinion, '0' in this paragraph is not simply the number
zero,
> it is just a generic symbol or a wild-card as vb is too. Therefore I
> interpreted '0' always as a wild-card for the neutral element of
addition in
> the value space related to the animated attribute or property. Is this
> correct?
> -> If yes, I suggest to add something like this:
> 'Note, that '0' is used here as a generic symbol for the neutral element
of
> addition for the value type of the animated attribute or property. For
example
> for animateColor '0' is used here as a symbol to be replaced with black
or
> #000 or rgb(0,0,0), for animateMotion this is a symbol to be replaced
with 
> the value of the origin 0,0. Similar substitutions have to be done for
any
> attribute value.'

Changed the definition to ...list with 2 values, the neutral element for
addition for the domain of the target attribute (denoted 0) and vb

> ---
> 
> 'to animation
> This describes an animation in which the animation function is defined
to
> start with the underlying value for the attribute, and finish with the
value
> specified with the to attribute. Using this form, an author can describe
an
> animation that will start with any current value for the attribute, and
will
> end up at the desired to value. 
> 
> A normative definition of a to animation is given below in To
animation'
> 
> -> missing a '.' at the end

Fixed.

> -> Note that the reference still points to the informative box, not to
the
> normative box, this is maybe a little bit confusing within a normative
> sections, because it it noted, that it references a normative
definition.

The link points to a section.  The section starts with an informative box
but also contains normative text.

> 'A to animation of an attribute which supports addition is a kind of mix
of
> additive and non-additive animation.'
> 
> -> Well, this is now indicated only as informative, this was not the
case in
> SMIL2.
> My interpretation now is, that it is not important, if the attribute
supports
> addition or not, one has to follow the normative formulars below anyway?

> But then the sentence above can be shortend to avoid confusion:
> 
> -> 'A to animation of an attribute is a kind of mix of additive and
> non-additive animation.'

The definition of to animation for a discrete animation should be
normative.  This means that the bit "which supports addition" is still
relevant.  The discrete case was added to the normative definition.


----

Received on Tuesday, 23 October 2007 09:08:34 UTC