Re: discussion about temporal scenario modelisation

Thanks for your reply. I see your point. 
Below I will try to explain our approach. 

In my previous response it was my intention to show that 
in some extent SMIL supports a solely constraint-based 
authoring. The hierarchical approach can be seen as a layer 
on top of this "constraints" layer. It should add in readability 
and ease of authoring as the (coarse) temporal flow can be grabbed 
more easily. In addition the hierarchical information is available 
for other uses.

Before further answering your mail, I like to report that last 
week the SYMM working group has met together for interoperability 
testing. We compared various SMIL-players with respect to each 
other and with respect to the draft as we specified it.

We didn't encounter large deviations or parts of the draft which 
reveal a thorough review need. We identified some spots in the draft 
which could be more specific. That's what we are going to do in the 
coming weeks. In conclusion, we are quite happy with the result.

jourdan wrote:
> >
> > As an example of a constraint-based specification you give
> >
> >   A meets B
> >   B meets C
> >   I starts A
> >
> > I would say that this type of authoring is also supported by SMIL:
> >
> >   <B begin="id(A)(end)"/>
> >   <C begin="id(B)(end)"/>
> >   <A begin="id(I)(begin)"/>
> we do not understand how this group can be incorporated in a SMIL
> specification ?
> You are obliged to encapsulate these three objects by using a seq or par
> node, aren't you ?

Yes, in this case you should use the par construct. In SMIL 
it is required to have a single root element.

> If so, how the synchronization by qualified events is merged with the
> seq or par semantics ?

That's specified in the draft (one of the parts we want 
to clean up):

The synchronization attributes "begin" and "end" can be added to 
any schedule element. These attributes change the default begin 
and end times of the element. A synchronization attribute can be 
an offset value or a qualified event.

If the value of a synchronization attribute is an offset value, 
its semantics depends on the parent of the element containing 
the synchronization attribute:

  .  If the parent is a parallel element, the value defines a 
     time-offset from the beginning of the parallel element 
     (see Figure 6.4). 
  .  If the parent is a sequential element, the value defines a 
     time-offset from the end of the predecessor element (see Figure

If the value of a synchronization attribute is an element event, the 
attribute specifies that an element should begin or end when a
event occurs in another element (see Figure 6.6). This element must be 
a sibling of the element with the synchronization attribute.

You may also read <URL:>
and <URL:>

> The aim of the two following remarks/questions is to show that the
> temporal "events synchronization" proposed in SMIL is not equivalent to
> temporal constraints as used in Madeus (or ISIS, or CHIMP, TIEMPO, ...)

I agree the constructs are not equivalent completely. My purpose was 
to show that the concept is there. We used it in another direction.

An important factor concerns causality. We aim to prevent constraints 
which induce an action before the related event occurs (negative delays, 
or requiring a continuous media to adjust its speed such as to end at 
a certain moment in future). Neither do we allow loops in the temporal 
graph (tree). 

Causality implies that an object can be synchronized to only one event. 
You cannot specify something like 
   <audio begin="id(obj_1)(2s)" begin="id(obj_2)(3s)"/>

SMIL doesn't support conditional synchronization (except, maybe, 
via misusing the switch). Neither are begin/end ranges supported: 
an object begins or ends at a certain (specified) moment, not in 
a range.

A consequence is that an existing constraint might need to be re-edit 
in case another constraint gets added. This is the case in your first 

> 1) Suppose i want to add to your example a new objects E in sequence
> before A.
> The temporal constraints to addd to the previous set
>   A meets B
>   B meets C
>   I starts A
> is : E meets A

Adding "E meets A" yields that A is specified to begin both when 
E ends as well as when I starts. As said, such a double is not 
allowed in SMIL, and the "I starts A" constraint need to be re-edit 
into "A starts I" (or in "E meets I"; similarly "E meets A" could be 
added as "E meets I", allowing the existing constraints to stay

  <B begin="id(A)(end)"/>
  <C begin="id(B)(end)"/>
  <I begin="id(A)(begin)"/>
  <A begin="id(E)(end)"/>.

Instead of re-editting the constraint another solution is to group 
objects such that a constraint applies to a group. Here we start 
building the SMIL-tree. But, again, you're not obliged to do so! 
(If a tree is created, one can always flatten it upto the root node.)

> Conflicts in smil are often solved by taking something like a "first
> arrived" policy (minimum between two possible durations).
> If this is the case here, it means that one of the two synchronisations
> will be lost.

I don't understand you. If two synchronization specifications are 
in conflict some resolution scheme is required. If the synchronization 
is not allowed to be in a range and the object is not allowed to stretch 
or to shrink, the remaining solution I see is to specify a precedence 
rule. Do I overlook some alternatives?

The precedence rules in SMIL like "minimum wins" are related to 
situations where the author wants to specify an ending while 
the duration of the objects is not known in advance. The endsync 
attribute has been defined for that purpose. Precedence rules are 
added to resolve possible conflicts.

> 2)
> When I express in Madeus that two objects are linked by an equal
> constraint
> A equal B.
> One can think that it is equivalent to
> par
>   <A begin ="id(B) (begin)", end = "id(B) (end)>
>   <B>
> /par

(The common way to author would be 


maybe with sync="hard" added in the par). 
An endsync attribute can be added to the par element to specify 
the end-behavior. SMIL doesn't support automated stretching and 
shrinking of continuous media such as to let them end on some 
point in the future. (That would require that the natural duration 
of the object is known, in the worst case causing a delay equal 
to that duration; plus some buffering consequences.)

> Suppose now that A and B are two moving objects which have to reach some
> different fixed points on the screen. In addition the author can adjust
> their speed as he wants.
> The semantic expressed by A equal B is: A and B starts and finishes at
> the same time, and none of them has been interrupted (i.e they reached
> their final position).
> With a constraint-based approach the temporal formatter chooses a
> well-suited speed for each objects.

I am a little confused: does A meets B specify that both objects are 
of equal duration, or does it specify that the dynamic actions applied 
on them (move the objects) are of equal duration?

As said, automated stretching and shrinking to meet future 
synchronization points is not supported by SMIL. Dynamic behavior 
is not yet defined.

(Btw. assume A is of shorter duration than B and "A equal B" is 
specified, how is it decided if A is to be stretched, or B to 
be shrinked, or both A stretching and B shrinking? Or do have 
"A equal B" and "B equal A" different semantics? They have not 
in Allen's description, have they?)

> In SMIL, (from our understanding) the author is obliged to fix the
> duration (and so the speed) of each objects, then the three following
> cases are possible :
> 1) he give the same duration of the two objects => everything is ok.
> 2) A is shorter than B =>  the end point syncronization is not satisfied

As commented above.

> 3) A is longer than B => A is interrupted when B ends, it means that A
> do not reached the position wished by the author.

The endsync-attribute is available for this purpose.

>  On this example, it is very simple to give the same duration of the two
> objects, but if I take a more complex one (Two sequences (A,B,C) and
> (E,D) synchronized at their beginning and end point).
> A meets B
> B mets C
> D meets E
> A starts D
> E finishes C
> this task is not so trivial for the author. Moreover, if he inserts a
> new object in one
> sequence, he has to compute again these values.
> Here, we point out one major advantage of using constraints.

As commented above.

Kind regards,
Warner ten Kate.


PS. I am interested to learn about the logical grouping in Madeus. 
Is it possible for you to answer my questions?

> Warner ten Kate wrote:
> > What I get from the figures in your document, in Madeus you
> > specify constraints between media-objects; sets of media-objects
> > with their constraints can be taken together into logical groups.
> >
> > Is this correct?
> > Is there any additional semantics to these logical groups
> > eg. are there (structured) dependicies between these groups?

Philips Research Labs. WY21 ++ New Media Systems & Applications
Prof. Holstlaan 4 ++ 5656 AA  Eindhoven ++ The Netherlands
Phone: +31 4027 44830
Fax:   +31 4027 44648

Received on Thursday, 19 February 1998 12:23:57 UTC