Thierry Michel | 10 May 11:20 2007
Picon

Re: errors (?) in FPIs listed in SMIL 2.1 REC


olivier,

Yes these are small typo errors that we should correct in our SMIL errata
page.

>
> Hello,
>
> I noticed a couple of odd things, possibly tiny mistakes, in the REC
> for SMIL 2.1, in particular in
> «Table 7: Formal public identifiers and system identifiers of all
> files used in the SMIL 2.1 modular DTDs.»
> http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil-modules.html
>
>
> * -//W3C//DTD SMIL 2.1 Language //EN
> I haven't seen this FPI anywhere, shouldn't it be
> -//W3C//DTD SMIL 2.1//EN
> ?
> (more consistent with the FPI generally used for this profile, e.g
> http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil21-profile.html )
>
>
> * -//W3C//DTD SMIL 2.1 Mobile //EN
> has an extra space, shouldn't it be
> -//W3C//DTD SMIL 2.1 Mobile//EN
> ?
>
> If these are indeed (small) mistakes, I wish we (validator
(Continue reading)

Sjoerd Mullender | 25 May 14:21 2007
Picon

Re: frozen value for discrete animation

Patrick Schmitz wrote:
> By even multiple we intended that it was an integer multiple, with no
> fractional or partial multiple result.  We should probably have said
> "integer multiple". To be really precise we would have to specify an
> (integer>0) multiple.
> 
> Our intent with "some" positive integer is "any". This is an English
> expression, common in mathematical descriptions. Sorry for any confusion.

I propose to change the wording to "integral multiple" to make it clear
that we're talking about proper multiples here.  Alternatively, we could
just leave out the word "even", but I think (as apparently the original
author did also) that an extra adjective should make it even clearer.

Sjoerd (member of the SYMM working group, so in a position to effect the
change)

> Patrick
> 
>> -----Original Message-----
>> From: www-smil-request <at> w3.org [mailto:www-smil-request <at> w3.org]On Behalf
>> Of Dr. Olaf Hoffmann
>> Sent: Friday, April 06, 2007 7:43 AM
>> To: www-smil <at> w3.org
>> Subject: Re: frozen value for discrete animation
>>
>>
>>
>> Hello,
>>
(Continue reading)

Patrick Schmitz | 25 May 18:03 2007

RE: frozen value for discrete animation


I would say "integer" and not "integral". The two are different in
(American) English, and the former is what I think we want. We could replace
"even" with "whole" or leave it out altogether. In (American) English, whole
numbers are another way to describe integers, and I think may even have the
additional restriction of >0. Again, for the picayune readers, we should
probably be explicit that integers <=0 are not allowed.

> -----Original Message-----
> From: Sjoerd Mullender [mailto:sjoerd <at> acm.org]
> Sent: Friday, May 25, 2007 5:21 AM
> To: Patrick Schmitz
> Cc: Dr. Olaf Hoffmann; www-smil <at> w3.org
> Subject: Re: frozen value for discrete animation
>
>
> Patrick Schmitz wrote:
> > By even multiple we intended that it was an integer multiple, with no
> > fractional or partial multiple result.  We should probably have said
> > "integer multiple". To be really precise we would have to specify an
> > (integer>0) multiple.
> >
> > Our intent with "some" positive integer is "any". This is an English
> > expression, common in mathematical descriptions. Sorry for any
> confusion.
>
> I propose to change the wording to "integral multiple" to make it clear
> that we're talking about proper multiples here.  Alternatively, we could
> just leave out the word "even", but I think (as apparently the original
> author did also) that an extra adjective should make it even clearer.
(Continue reading)

Dr. Olaf Hoffmann | 25 May 18:39 2007
Picon
Picon

Re: frozen value for discrete animation


Hello,
>
> I propose to change the wording to "integral multiple" to make it clear
> that we're talking about proper multiples here.  Alternatively, we could
> just leave out the word "even", but I think (as apparently the original
> author did also) that an extra adjective should make it even clearer.
>
> Sjoerd (member of the SYMM working group, so in a position to effect the
> change)
>

I think this can avoid some confusion. The given formulars
seem to be sufficient even without an additional adjective.

What I found about this at wikipedia:
'The integral value of a real number x is defined as the largest 
integer which is less than, or equal to, x, see floor function.'

Hmmm. The formular 
'AD = d*i for some positive integer i'
seems to be the important part of it to get 
proper implementations.

And what about the 'frozen value for discrete animation'?
I still think, this is different in SMIL2 as with the old 
SMIL animation recommendation or in SVG. They have
only the time interval model and 
'freeze the effect value at the last value of the active duration'.

(Continue reading)

Hugh J. Sloan III | 25 May 20:08 2007
Picon
Picon

Re: frozen value for discrete animation


May I suggest that all of us experience the latest consumer internet sensation and try the PGA Charity
Challenge on www.worldgolftour.com.  This has taken Silicon Valley by storm and is hailed by many CS/EEs
as a legal narcotic.  

-----Original Message-----
>From: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann <at> gmx.de>
>Sent: May 25, 2007 9:39 AM
>To: www-smil <at> w3.org, cogit <at> ludicrum.org, sjoerd <at> acm.org
>Subject: Re: frozen value for discrete animation
>
>
>Hello,
>>
>> I propose to change the wording to "integral multiple" to make it clear
>> that we're talking about proper multiples here.  Alternatively, we could
>> just leave out the word "even", but I think (as apparently the original
>> author did also) that an extra adjective should make it even clearer.
>>
>> Sjoerd (member of the SYMM working group, so in a position to effect the
>> change)
>>
>
>I think this can avoid some confusion. The given formulars
>seem to be sufficient even without an additional adjective.
>
>What I found about this at wikipedia:
>'The integral value of a real number x is defined as the largest 
>integer which is less than, or equal to, x, see floor function.'
>
(Continue reading)

Patrick Schmitz | 28 May 18:12 2007

RE: frozen value for discrete animation


I thought we had something in there somewhere to make the fill value take
the exclusive endpoint value (as all authors would want, if not expect, and
even if they understand the interval timing model as we do).

I forget where this was, but I remember discussing it. Will hunt around when
I get back online (writing from the train).

Patrick

>
> And what about the 'frozen value for discrete animation'?
> I still think, this is different in SMIL2 as with the old
> SMIL animation recommendation or in SVG. They have
> only the time interval model and
> 'freeze the effect value at the last value of the active duration'.
>
> For this example:
> calcMode="discrete"
> values="1;2;3"
> keyTimes="0;0.4;0.8"
> begin="0s"
> dur="10s"
> end="4s"
> fill="freeze"
>
> Because a time interval is exclusive end, the last value is 1
> and not 2 for the old SMIL animation recommendation or in SVG.
> With the SMIL2 timing modul it will get 1 with the 'cut off simple
> duration' or 3 with the 'dur value simple duration'.
(Continue reading)

Sjoerd Mullender | 29 May 10:20 2007
Picon

Re: [SMIL30 FWD] calcMode, keyTimes and examples

This is indeed an inconsistency which should be fixed.

Patrick, any ideas?  I'm referring to the first problem reported here
since I already have a tentative resolution for the second (fix both
example and accompanying text--see the other thread).

Dr. Olaf Hoffmann wrote:
> Hello,
> 
> I would like to (re)report a problem in the working draft
> of SMIL 3 (already reported for previous versions or
> working drafts of SMIL, but not corrected or discussed
> yet).
> 
> In 3.9.1 SMIL 3.0 SplineAnimation Module Attributes
> (Calculation mode attributes)
> it is noted about keyTimes:
> 
> ' 
>   For linear and spline animation, the first time value in the list must be 0, 
>   and the last time value in the list must be 1.
> '
> 
>  Later in the section "Interpolation with keySplines" we find the example:
>  
> ' 
>   <animate attributeName="foo" from="10" to="20" 
>      dur="10s" keyTimes="0.0; 0.7"
>      calcMode="spline" keySplines=".5 0 .5 1" />
> 
(Continue reading)

Dr. Olaf Hoffmann | 29 May 14:18 2007
Picon
Picon

Re: frozen value for discrete animation


> I thought we had something in there somewhere to make the fill value take
> the exclusive endpoint value (as all authors would want, if not expect, and
> even if they understand the interval timing model as we do).

No, if one understands this interval timing model and maybe the
mathematical concept of a limes, it would be surprising to have an
additional specific rule to get the exclusive endpoint. There is no
need for a specific rule. Some more of such exceptions and the 
interval timing model with exclusive end is not useful for anything ;o)

The main reason to discuss the situation of the exclusive end for
a continuous (linear, paced or spline) animation seems to be to
avoid that implementors have to identify this themselves as the 
correct limes in the interval timing model with exclusive end.
In a perfect world for those continuous animations there is no 
need for a specific rule, but I can understand this as a simplification 
for implementors. But for discrete animation these rules do not
create the correct result related to the mathematical limes
for the time interval model, therefore for the discrete animation 
the result from the simplifying formulars in SMIL2 gets 
counterintuitive using the exclusive endpoint as a frozen value.

With interactive begin or end the probabilty that it happens is
very low and the main application doing this with offset values is
to test, if the time interval model is implemented correctly in a viewer.
Else I cannot imagine any other expectation for this relatively
exotic situation for authors as the mathematical correct limes
within the interval timing model ;o)

(Continue reading)

Patrick Schmitz | 29 May 18:16 2007

RE: [SMIL30 FWD] calcMode, keyTimes and examples


I think at one point we had some idea about the last value of 1 being
implied, and then we made it tighter. This may be cruft left over from that,
but I want to be sure that we do not have anything left over that conflicts.
I will take a closer look at this tonight.

First thought is that to produce what the text describes, the code should
say:

   <animate attributeName="foo" from="10" to="20"
      dur="10s" keyTimes="0.0; 0.7; 1"
      calcMode="spline" keySplines=".5 0 .5 1 1 1" />

Patrick

> -----Original Message-----
> From: www-smil-request <at> w3.org [mailto:www-smil-request <at> w3.org]On Behalf
> Of Sjoerd Mullender
> Sent: Tuesday, May 29, 2007 1:21 AM
> To: Dr. Olaf Hoffmann
> Cc: www-smil <at> w3.org; Patrick Schmitz
> Subject: Re: [SMIL30 FWD] calcMode, keyTimes and examples
>
>
> This is indeed an inconsistency which should be fixed.
>
> Patrick, any ideas?  I'm referring to the first problem reported here
> since I already have a tentative resolution for the second (fix both
> example and accompanying text--see the other thread).
>
(Continue reading)

Dr. Olaf Hoffmann | 29 May 19:45 2007
Picon
Picon

Re: [SMIL30 FWD] calcMode, keyTimes and examples


> I think at one point we had some idea about the last value of 1 being
> implied, and then we made it tighter. This may be cruft left over from
> that, but I want to be sure that we do not have anything left over that
> conflicts. I will take a closer look at this tonight.
>
> First thought is that to produce what the text describes, the code should
> say:
>
>    <animate attributeName="foo" from="10" to="20"
>       dur="10s" keyTimes="0.0; 0.7; 1"
>       calcMode="spline" keySplines=".5 0 .5 1 1 1" />
>

No, 3.2.3:
'If a list of keyTimes is specified, there must be exactly as many 
values in the keyTimes list as in the values list.'

from-to are two values, not three ;o)

And the there is always a multiple of 4 numbers in the
keySpline list, here 4 for from-to or 8 for three keyTimes:

'Each control point description is a set of four floating point values: x1 y1 
x2 y2, describing the Bezier control points for one time segment.'

This may work (but did not test it and does not use from-to anymore):
dur="10s"
values="10;20;20"
keyTimes="0.0; 0.7; 1"
(Continue reading)


Gmane