Re: [SMIL30 LC comment] more about the fill attribute ( LC-1828)

....

> Working Group Resolution (LC-1828):
> There are three parts to this comment:

In general it is only one issue - backwards compatible
and well defined behaviour for fill...


>
> - When bringing the min attribute into the mix, the definition of the
> freeze value becomes counter-intuitive (to say the least).  It seems that
> the relevant parts of the animation chapter were written before the
> introduction of the min attribute in the Timing and Synchronization
> chapter and this addition was never properly propagated.  The working
> group has fixed the situation by using the intermediate active duration
> and the active duration to define the frozen animation function.
>

The definition and procedures for min and max seem to be taken
from the 'SMIL animation recommendation  04-September-2001'
and this was consistent with the fill value behaviour and propperly
defined including consistency with the SMIL interval timing model
in the old recommendation. This one has indeed its own problems,
but not related to min, max or fill ;o)

The inconsistencies and problems were introduced with the 
formulas for fill, obviously not using the timing model and 
obviously incomplete too. Therefore for a historical view the
problem is not related to min and max, it is only related to
the formulas in SMIL2/3 for fill ;o) And those formulas are 
obviously created later than the definition of min and max in the
'SMIL animation recommendation  04-September-2001'.

But using IAD and AD as suggested in my previous comment,
indeed this can complete the formulas in a useful way.
Obviously it depends on the wording, definitions and formulas,
not accessible to me, to analyse or to decide, if they do it in
a consistent and useful way.



> - When an animation is cut short and then frozen, the frozen animation
> function uses the time at which the freeze starts instead of (as is usual
> in e.g. frozen videos) the "last" value of the still active time.  The
> working group decided to leave this the way it is.  The functions are all
> well-defined and don't need any further refinement.  The fact that this is
> perhaps counter-intuitive with respect to the end point exclusive nature of
> SMIL timing is offset by the clarity of the functions. Note that this is
> similar to a sequence of elements which is cut short just when a new child
> is supposed to start.
>

This does not solve any problems concerning backward incompatibilities
with the SMIL animation recommendation  04-September-2001
3.3.5 and the derived definitions in SVG 1.0/1.1/ Tiny 1.2.

To resume the pros for the different methods:

a) limes/time interval method as suggested:
- backward compatible with 'the SMIL animation recommendation
  04-September-2001'
- compatible with SVG 1.0/1.1/ Tiny 1.2 and no problems to be expected for
  future SVG versions. No necessary overwrite rules or specific
  considerations in SVG required to ensure backwards compatibility and using
  newer SMIL recommendations for details
- intuitively understandable and simple
- possible to derive any behaviour from one simple rule and the SMIL timing
- respects the SMIL time interval model and uses it
- formulas to simplify correct implementation can be derived and provided as 
  informative notes without any problems.

b) formulas from SMIL 2/3
- the WG saves work and time to fix the formulas and to write errata



So, what to do, if the WG thinks, the advantage of b) is much more important
as that of a)?

In this case I would suggest to add an informative note to the formulas, that
the behaviour defined in SMIL 2/3 is backward incompatible to that defined
in the SMIL animation recommendation  04-September-2001. 
Therefore implementors of both or on profiles still depending on the 
SMIL animation recommendation  04-September-2001 are informed, that
they have to implement a switch depending on the used version.
Authors get informed, that they have to decide between the different 
profiles to get the behaviour they need. Authors from other specifications
may take this note as a hint to write overwrite rules to prevent backwards 
incompatibilities in their specifications.

Well, I do not think, that this really solves the real problem, but it
simplifies to work around the incompatibilties in SMIL with a certain 
amount of additional work for any interested group ;o)



> - When multiple move commands with zero-length lines happen at the same
> instance of time (when using paced animation), the last of these move
> values is the one that is used for freezing at that time.  The end point
> exclusive nature of timing already suggests that the zero-length lines all
> end their duration before this time instance.  In your example, the value
> on which the animation would freeze is then 500,500.  This is in line with
> the previous point.
>
>
> ----

The end point exclusive nature of timing cannot be used for the current
formulas in SMIL2/3, because they use another (currently incomplete) model, 
therefore such a situation is not covered by the formulas.
I think, a similar situation appears with

calcMode="discrete|linear|spline"
values="0;1;2;3;4" 
keyTimes="0;0.5;0.5;0.5;1" 

This can indeed been avoided using the SMIL time interval model with
method a) to fix the incompatibilities in the formulas as already suggested.

In case of solution b) (see above), however the WG cannot avoid some
additional work here providing even more specific formulas to cover
such exotic situations just for completeness, because the current model
indeed excludes the SMIL timing interval model for somehow 
discontinuous animation effects.

Received on Saturday, 17 November 2007 17:11:04 UTC