At 13:30 +0100 3/11/97, Andreas Kraft wrote :
>Emmanuel,
>
>On Mon, 3 Nov 1997, Emmanuel BEUQUE wrote:
>
>> Following what it is said at the last sentence of section 53.3, "it is
>> possible for a link to deactivate itself in its LinkEffect. Such an action
>> shall be postponed until the LinkEffect has been completely executed."
>>
>> This last sentence seems problematic to me. Suppose the linkEffect
>> deactivate itself and then make an action that would cause the link to fire
>> again it it was active.
>>
>> Shall we understand that we would go into an infinite loop or should
>> we rather considered that :
>>
>> The link is deactivated immediately but all remaining elementary actions
>> keep queued in the execution stack managed by the MHEG-5 engine.
>>
>> (That's a proposal of modification for section 53.3).
>
>No, there is actually no problem. The fourth paragraph of 53.3 says:
>
>"As a direct result of a LinkEffect being executed, synchronous events
> may occur. These events shall be dealt with directly by the MHEG-5
> engine. In other words, after the execution of each elementary action,
> the MHEG-5 engine shall check if any additional Links have fired as the
> result of a synchronous events occurring. If this is the case, that Link
> and all its effects shall be completely processed before the MHEG-5
> engine continues to process the next elementary action of the original
> Link."
I perhaps wasn't clear but I don't see the relation of this with the
problem I asked. I fully agree with the mechanism you described above
concerning synchronous events and links that are triggered immediately. I
find it very useful and use it very often. But my problem is with the last
sentence of 53.3, which is IMHO an exception.
The mechanism of the link deactivation that is postponed when the target is
itself, is described only there and seems confusing to me, on an author
point of view.
Remember I'm on the MHEG authoring side and I regret that the standard is
so much engine oriented (it is perfect to write an engine in an
object-oriented language but it is not so easy to build the behaviour you
want when you author an application).
Imagine you were an author and look at the class definition. Look at
13.4.Deactivate. There is absolutely no mention there that, if the target
is the link itself, the dectivation behaviour is only done when all other
elementary actions of the link effect has been completed. You only see in
13.1.2.LinkEffect that elementary actions are executed in synchronous order.
That's why I think there is a contradiction there. I'm curious to know how
your all engines deal with this particular exception.
In my opinion, the last sentence of 53.3 should be removed or replaced by
what I proposed. It seems to me that there is no problem if the link is
deactivated during the execution of the linkEffect. This shouldn't shorten
the execution of the linkEffect action anyway (or give me the reason).
To handle synchronous events (and their possible link effects), an MHEG-5
engine already has to manage a kind of queue of elementary actions. I don't
see any problem to store all elementary actions of the link effect in this
queue as soon as the link is fired.
Any comment ? Any other opinion ?
__________________________________________________________________
Emmanuel BEUQUE mailto:ebeuque@pratique.fr
MediaServ tel: +33 (0) 2 99 64 35 64
Multimedia consultant & developer fax: +33 (0) 2 99 64 36 65