Re: Towards an event model for SMIL

Hi Jennifer and Nils,
Sorry for the delay but we were all very busy in the group because of a new
public release of the standard.
It was very interesting for me to read your document since i also took some time
to think about the SMIL state model issue few months ago and reading your
document refreshes my memory.


Some comments now on your document.
First of all you make a valuable job on understanding the link between children
and time container transitions. You catch the main ideas of the Smil time
models, however i have some  concerns on the  following points :

* if i correctly understand your proposition you want to associate a scheduler
and a Smiley machine to each element of the document. 
Is this Smiley machine the same for each element ?
Reading the document i suppose that the answer is yes and thus i didn't
understand how your model handles sequential time container since when the
scheduler triggers the "activate" transition then you must not send the output
WakeChildren to each children but only to the first one and when this first
children ends the next one must be wake up and so one. I didn't understand which
part handles this semantic in your proposition ?
This is the major concern i have about your work.

* you didn't add a "paused" state to your model, is it because you didn't take
care to the <excl> time container at this stage of your work ?
If you think that the paused state must not be distinguish from the active state
then i didn't agree with you when you said that the active duration is the total
time spent on the active state since the element can be paused. 

* Let's consider the following example :
<par  dur="12s"  >  
    <img id="A" dur="4s" begin="3s;9s" />
    <img id="B" dur="15s"/>
  </par>

The behavior of this example is :
at t=0s B is shown until t=12s
at t=4s A is shown until t=7s
at t=9s A is shown until t=12s
at t=12s the two images disappear.

It seems to me that your model fails on this example since at t=7s the smiley
manchine associated with A is in its finished state (it ends its first active
duration) and their is no way to activate it again.

 
* the difference between sync-arc and beginEvent/endEvent : 
A sync-base value is propagated as soon as it is possible to compute its value
and not (as it is handled in your model) when the sync element effectively begin
or end.
Moreover the computed value should be different from the observed value (see the
example below).
This point  was not clearly explained in the last draft so it is not surprising
at all that you didn't make this difference.
see the section in the new public draft : Events and event model


For instance,
<par>
  <par  endsync="first"  >  
    <img id="A" dur="12s" end="click"/>
    <img id="B" begin="6s" dur="10s"/>
  </par>
  <img id="C" begin="B.begin" dur="12s"/>
</par>

In this example, B may never begin (if the user click on A before 6s), but its
begin value is  used to compute the beginning of C, so C will begin at t=6s.
Your model didn't catch this semantic. In fact, what you did corresponds to this
example :
<par>
  <par  endsync="first"  >  
    <img id="A" dur="12s" end="click"/>
    <img id="B" begin="6s" dur="10s"/>
  </par>
  <img id="C" begin="B.beginEvent" dur="12s"/>
</par>

Here, image C will not begin if the user clicks on A before 6s.
What you call Sync arc environment is in fact an event handler.


I will now give some feelings about how i will start to proceed if i would have
to define a state model for Smil. 

* it seems to me that it will be more interesting to replace your finished state
by a "frozen" state which model the freezing duration of the object. Since the
interest of such state machine is that at each state of the model corresponds a
physical status of the element. 
Active : the content of the element is being  presented
Frozen : the content of the element is frozen
idle : the content of the element is not being presented at all.
Paused: the presentation of the element is paused 
>From an implementation point of view it will be really helpful
(I didn't know what to do with your dormant state, but ...)


*I found your model difficult to understand because Environment Events and
ParentEvents  are send both to the SmileyMachine and the scheduler. For instance
the looping transition on Idle with the input BeginElement  first surprised me
since i didn't understand why a beginElement didn't make the element active. I
finally understand that this beginElement is also received by the scheduler
which in its turn send the activate input to the SMiley machine. So its ok but
complex ...
Moreover it makes me feel that  with this solution the control is shared between
the two entities.
So why don't you  send these events to the scheduler only and put the control
only in this entity ? I think that it would be clearer.
In fact, if you make that the link between the activation of a parent time
container and its children will be hidden in the scheduler and this is something
that you want to avoid, but at least for EnvironmentEvents it can be made.


I hope that these comments will help you,

Muriel 

"Jennifer L. Beckham" wrote:
> 
> hello SMIL people:
> 
> Here at AT&T Research, we've been looking at SMIL as a way of handling
> timing constraints for speech applications.  The orthogonal time
> containers (par, seq, and excl) within SMIL?s Timing and
> Synchronization Module provide us with a good foundation for
> developing intricate speech-aware multimedia systems.  We're working
> from a programming language point of view and have started on a formal
> semantics for SMIL?s Timing Module.
> 
> Part of our process involves gaining a understanding of the states and
> transitions for a given time container.  We found the section titled
> ?State Transition Model? in the Timing Module working draft
> helpful, but also a bit confusing. Our greatest struggle was in
> matching up the state diagram for an element with the informal
> semantics in the draft.  In particular, the diagram does not very
> clearly explain relationships with parent containers, synchronization
> with other elements, and the evolving SMIL event model.
> 
> So, we've tried to define an event flow and state machine semantics
> for SMIL. We try to elucidate the timing and the scheduling properties
> of elements by separating the sync-arc relationships of elements from
> the activation and playing of an element. Our work is summarized in
> the attached html document.  Basically, we wanted to turn the state
> diagram into something that precisely explains fundamental parts of
> SMIL.  For this reason, we are using a simple event oriented model,
> where the state diagram is a Mealy machine that define fundamental
> concepts such as durations.
> 
> We would be very happy to receive comments on the model; have we
> understood SMIL?
> 
> Thank you,
> Jennifer L. Beckham
> Nils Klarlund
> 

-- 
__________________________________________________
            Muriel.Jourdan@inrialpes.fr
Tel : 04.76.61.53.58            Fax : 04.76.61.52.07
        Unite de Recherche INRIA Rhone-Alpes,
     projet OPERA ( http://www.inrialpes.fr/opera )
          ZIRST, 655 avenue de l'Europe,
       38330 MONTBONNOT SAINT MARTIN, FRANCE

Received on Friday, 7 July 2000 07:56:49 UTC