- From: Thierry Michel <tmichel@w3.org>
- Date: Thu, 22 Nov 2007 14:18:52 +0100
- To: Dr.O.Hoffmann@gmx.de, www-smil <www-smil@w3.org>
Dear Dr. Olaf Hoffmann ,
The SYMM Working Group has reviewed the latest (response) comment 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 27 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] *( LC-1828) more about the fill attribute (Saturday, 17 November)
http://lists.w3.org/Archives/Public/www-smil/2007OctDec/0113.html
2. http://www.w3.org/TR/2007/WD-SMIL3-20070713/
=====
Your *initial* comment on Synchronized Multimedia Integration Language
(SMIL 3.0)
W...:
> Hello SMIL working group,
>
> there is an inconsistency in
> the behaviour of the fill attribute
> in SMIL 3 (and SMIL 2).
> The discussion was already started
> for SMIL 2 ( for example
> http://lists.w3.org/Archives/Public/www-smil/2007JanMar/0017.html
> and the following)
> but was not finished
> yet and applies to the LC of
> SMIL 3 as well.
>
>
>
>
>
> First assume this example with a video
> having only 3 frames:
>
> [0s;1s) : red frame
> [1s;2s) : green frame
> [2s;3s) : blue frame
>
> <video src="3sRGB3frames"
> alt="video with 3 frames; duration 1s per frame; frames: red, green,
> blue"
> dur="3s" begin="1s" end="3s" fill="freeze" />
>
> .... and a related animation example:
>
> <animate attributeName="color"
> values="red;green;blue"
> calcMode="discrete" fill="freeze"
> dur="3s" begin="1s" end="3s" />
>
> Presentation without an end attribute is therefore in both cases:
> [1s;2s) : red
> [2s;3s) : green
> [3s;4s) : blue
> and later blue too.
>
>
> To get the correct behaviour with the end attribute
> lets resume some sections:
>
>
> 11.4.5
>
> The instance times lists
>
> 'offset-values are the simplest. Each offset-value condition
> yields a single instance time. This time remains in the list
> forever, and is unaffected by reset of the element, or by
> repeat or restart of the parent (or other ascendants).'
>
> Examples above
> -> instance time list for begin: 1s
> -> instance time list for end: 3s
>
> 11.4.3
>
> Dur value semantics
>
> 'dur
> Specifies the simple duration.'
>
> Examples above
> -> simple duration: 3s
>
>
> The fill attribute
>
> 'For visual continuous media, the "frame" that
> corresponds to the end of the last instance of the
> simple duration is shown.'
>
>
> -> what is the 'end of the last instance of the
> simple duration'?
> A duration is not directly related to a moment in time.
> In the video example above the simple duration
> is related to an interval [1s;4s).
> Instances seem to be related to
> moments, not to (time) intervals.
> Therefore if an instance is only a moment
> it is obscure what the end of this moment is.
>
> The related end is at 3s. This is the last end
> instance time according to 11.4.5.
> But this does not answer, what the end
> of the last instance of the simple duration is.
> 1s the begin, 3s the (exclusive) end of the
> interval related to the (cut off) simple duration.
>
> If 'last instance' nevertheless is meant to be
> related to intervals (the last repetition of
> the simple duration?), the 'frame'
> corresponding to the end of the last
> instance of the simple duration is
> the green frame in the video example
> above.
>
>
> 'For algorithmic media like animation, the value
> defined for the end of the last instance of the
> simple duration should be used.'
>
> -> what is the 'value defined for the end of
> the last instance of the simple duration'?
>
> Here we have almost the same arguments
> for the animate element as for the
> video element. The simple duration
> is related to an interval [1s;4s).
> Instances seem to be related to
> moments, not to (time) intervals.
> Therefore if an instance is only a moment
> it is obscure what the end of this moment is.
>
> The related end is at 3s. This is the last end
> instance time according to 11.4.5.
> But this does not answer, what the end
> of the last instance of the simple duration is.
> 1s the begin, 3s the (exclusive) end of the
> interval related to the (cut off) simple duration.
>
> If 'last instance' nevertheless is meant to be
> related to intervals, the value
> corresponding to the end of the last
> instance of the simple duration is
> the color green in the animate example
> above.
>
> -> This looks as a 'good' interpretation, because it fits to the
> definition of the fill attribute in the
> SMIL animation recommendation 04-September-2001
> http://www.w3.org/TR/2001/REC-smil-animation-20010904/
> 3.3.5:
>
> 'freeze
> The animation effect F(t) is defined to freeze the effect
> value at the last value of the active duration.'
>
> -> Because the active duration interval is inclusive begin
> and exclusive end the frozen value is green.
>
> -> Because SVG 1.0/1.1/ Tiny 1.2 use the same definition,
> this is consistent with them too.
>
> -> In SMIL 1.0 I could not find any detailed description
> for the fill behaviour related to the video example.
>
>
> However there is a problem with the SMIL3 section 3.4.5 ...
> freezing animations.
> The formulas given in this section are consistent with
> this interpretation if calcMode is linear, paced or spline
> (There is an exception related to animateMotion using
> the path element, see below), but not always if it is
> discrete.
> With these formulas the frozen value of the
> animation example above would result in blue and
> not green.
> Therefore there is a probable contradiction between
> SMIL 3 Chapters 11.4.3 and 3.4.5 and there
> is an obvious incompatibility between SMIL 3
> Chapter 3.4.5 (respectively SMIL2) and the
> SMIL animation recommendation 04-September-2001
> 3.3.5 and the derived definitions in SVG 1.0/1.1/ Tiny 1.2.
>
> This causes already some confusion in SVG Tiny 1.2,
> because this references already SMIL 2.1, but the
> inconsistent formulas cannot be used, because they
> do not fit to the its definition of fill for calcMode
> discrete.
>
> Therefore my suggestion is to do some minor changes to
> the normative section for fill in SMIL 3.0, 3.4.5 and
> to add an errata to SMIL 2 to fix this problem.
> Unfortunately the specific rule for the case where the
> active duration is a multiple integer of the simple
> duration can be found already in the
> SMIL animation recommendation 04-September-2001,
> therefore to avoid compatibility problems, this has to
> be taken into account too.
>
> The change could be something like this:
>
> old:
> 'Normative
> The frozen animation function, ff(t),
> for an element with active duration AD, is given by
> ff(t) = fc(t) for all times t: 0<=t<AD (i.e. before it is frozen)
> When the element is frozen, t is effectively equal to AD.
> ....' (etc)
>
> new:
> 'Normative
> The frozen animation function, ff(t),
> for an element with active duration AD, is given by
> ff(t) = fc(t) for all times t: 0<=t<AD (i.e. before it is frozen)
> and
> ff(AD)= limes (e>0 to 0; fc(AD - e))
> with the following exceptions:
> If AD is an multiple integer of d, i.e. AD = d*i for some positive
> integer
> i ,
> and the animation is non-cumulative, ff(t) = f(d).
> If AD is an multiple integer of d, i.e. AD = d*i for some positive
> integer
> i ,
> and the animation is cumulative, ff(t) = f(d)*i.
>
> Informative
> If the limes is elaborated, this results in the following rules.
>
> For calcMode[reference related section] linear, paced and spline
> (and no animateMotion with path fragments separated from each
> other):
>
> When the element is frozen, t is effectively equal to AD.
> ...' (etc)
>
> and additionally:
>
> 'For calcMode discrete (or animateMotion with
> path fragments separated from each other):
> The frozen value is the last value of active
> duration. Note that the active duration is related to a
> time interval with inclusive begin and exclusive end.
> Therefore if the end of active duration meets exactly
> the time, the animation jumps to a new value, this jump
> does not take place. The only exception to this is a
> keyTimes value of one and the active duration
> is an integer multiple of the simple duration, then the
> value related to keyTimes 1 is used as a frozen value
> respectively the multiple of the value for cumulative
> animations as defined above.'
>
> ------------------------------------
>
> Details about the problem with
> animateMotion using paths with several M/m
> commands...
>
> To identify this we can use the following
> example:
>
>
> <animateMotion calcMode="paced"
> path="M100 100 m100 100l100 100
> m100 100l0 0
> m100 100l100 100
> M0 0"
> dur="6s"
> fill="freeze"
> repeatDur="as specified" />
>
> If repeatDur is not specified at all we get
> the following motion:
>
> time [0s;3s) motion from 200,200 to 300,300
> time [3s;6s) motion from 500,500 to 600,600
> frozen value at 6s and later: 0,0
> (M 0 0 creates a bad or empty interval of length
> zero, but defines the last value of the animation,
> this is similar for calcMode paced and
> path fragments like 'm100 100l0 0' or
> 'm 100 100z', always ignored in the animation,
> if this is not the last path fragment and the
> active duration is not an integer multiple of
> the simple duration. However for calcMode
> linear (or spline) path fragments like
> 'm100 100l0 0' or 'm 100 100z' take their
> fraction of time, the motions stops in this
> time interval).
>
>
> Now we assume repeatDur="3s"
>
> time [0s;3s) motion from 200,200 to 300,300
> frozen value at 3s and later: 300,300
>
> As we can see, this behaviour is somehow
> related to a discrete animation and the
> formulas in SMIL 3.0, 3.4.5 have another
> problem related to the path fragments of
> zero length. Because the time 3s can be
> related to three values:
> 300,300; 400,400; 500,500
>
> The suggested and consistent limes rule
> from above avoids such problems using
> simply the SMIL time interval model.
>
>
> --------------------
>
> Another minor problem with the formulas for the fill attribute
> in 3.4.5:
>
> To identify this, we can use the keyTimes 1 example from
> 3.9.1:
>
> '<par dur="30">
> <animate calcMode="discrete" repeatCount="2" dur="10" fill="freeze"
> accumulate="[as specified]" keyTimes="0.0; 0.5; 1.0" values="0; 1;
> 2"/>
> </par>'
>
> Lets assume an additional min="21s".
> This is the case in 11.4.3 (min/max):
> '... otherwise the element is played normally for its
> repeating duration (or simple duration if the element does not repeat)
>
> and then is frozen or not shown depending on the value of the fill
> attribute'
>
> Now the active duration is 21s, therefore not an integer multiple of
> the
> simple duration 10s anymore.
>
> But in 3.4.5 'Freezing animations'
> this exotic situation is not described, because neither the
> animation function at 21s nor at 20s is formally defined.
> Maybe now the frozen value has to be 1 for the non cumulative case
> and 3 for the cumulative case just due to the SMIL time interval
> model because there is no other specific rule. Correct?
> Maybe, but probably not intended.
> Maybe this requires an additional note or a precision, for example
> that the frozen behaviour is determined as if the active duration is
> not corrected with the min attribute, if the corrected active duration
> is not smaller as the uncorrected active duration.
> Not nice to implement, but somehow another side effect of this
> 'multiple integer' rule...
Working Group [2nd] Resolution (LC-1801):
Thank you for your comment.
At this stage the working group would like a clear yes or no answer from
you, as we need to move forward to avoid delaying the SMIL 3.0 spec.
Are you satisfied with the working group resolution?
If not, then we will acknowledge your answer.
Note that the resolution for this LC comment LC-1828: more about the
fill attribute) the resolution was agreed in a joint meeting with the
SVG working group.
In order to facilitate your answer, here are the relevant changes to the
Animation chapter. The SYMM and SVG working groups have agreed to issue
an erratum for the Animation chapter of SMIL 2.1.
The definition of the cumulative animation function has been changed.
This is only a change in wording, not in effect. The change was to make
sure that the functions fi(t) were defined in all cases:
<quote>
First we define some intermediate functions. The first iteration f0(t)
is unaffected by accumulate, and so is the same as the original simple
animation function definition. Each subsequent iteration adds to the
result of the previous iterations:
f0(t) = f(t)
If the animation is non-cumulative, then:
fi(t) = f(t - (i*d)) for any integer i > 0.
If the animation is cumulative, then:
fi(t) = (f(d) * i) + f(t - (i*d)) for any integer i > 0.
The cumulative animation function, fc(t), for any simple animation
function f(t) is then:
fc(t) = fi(t), where i = floor(t/d).
</quote>
The significant change is in the definition of the frozen animation
function. This now uses the Intermediate Active Duration as input.
<quote>
For an element with active duration AD and intermediate active duration
IAD, we define the repeat duration rd as:
rd = min(AD,IAD).
The frozen animation function is then given by:
ff(t) = fc(t) for all times t: 0<=t<rd;
ff(t) = ff(rd) for all times t: rd<=t<=AD where ff(rd) is defined below.
This is the value before the element is frozen.
When the element is frozen, t is effectively equal to AD, which
according to the above definition is equivalent to saying t is
effectively equal to rd.
In the following equations we define ff(rd).
If rd is not an integer multiple of the simple duration d, then ff(rd) =
fi(rd), where i = floor(rd/d).
This is equivalent to fc(rd), except that fc(t) is not formally defined
for t=rd. In this case, the equations remain consistent, and so the
equivalent of fc(rd) is used for the frozen value ff(rd).
If rd is an integer multiple of d, i.e. rd = d*i for some positive
integer i, and the animation is non-cumulative,
ff(rd) = f(d).
If rd is an integer multiple of d, i.e. rd = d*i for some positive
integer i, and the animation is cumulative,
ff(rd) = f(d) * i.
Note that f(d) is a shorthand for the "last value defined for the
animation function" (e.g., the to value or the last value in the values
list).
Also note that if the fill behavior of the animation element is
"remove", the animation effect is removed at the end of the repeat
duration and the definition of fc(rd) is not used. The remainder of the
active duration (if any) is only relevant for synchronization purposes.
</quote>
See our earlier resolution.
http://lists.w3.org/Archives/Public/www-smil/2007OctDec/0095.html
Received on Thursday, 22 November 2007 13:19:10 UTC