Many thanks for your answers, but I think you didn't see exactly what I meant.
À (At) 21:19 +0100 3/11/97, Andreas Kraft écrivait (wrote) :
>> 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.
>
>Yes, it is an exception. Consider a link that deactivates itself. Should all
>the pending actions be removed? I don't think so.
Neither do I, Andreas. See what I proposed. IMHO, all the pending actions
should be kept in the actions queue, but the deactivate action should be
executed synchronously (as defined in 13.1.2). Would it really be a problem
? I don't see in MHEG why the deactivation of a link should remove all its
remaining LinkEffect actions from the action queue. Is it said so somewhere
? If so, please tell where. The link deactivation should only prevent it to
fire again, according to 13.1.2.LinkCondition (tick 1). I think nothing is
said about pending actions so why remove them ?
If actions do not have to be removed, I don't see the aim of this last
sentence of 53.3. It creates an exception where there no need of IMHO.
You must admit that MHEG standard usually try to define as few exceptions
as possible, so why defining one there ?
>> That's why I think there is a contradiction there. I'm curious to know how
>> your all engines deal with this particular exception.
>
>Can you provide us with a simple test application, please?
I could but I haven't one just now. I will try to give one soon.
>> 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).
<snip>
>No, it should not be removed. I can not see that the standard is broken
>here. However, I aggree that the important explanations should be moved
>as a note to 13.1.2.
I think it is broken since it is the only occurence where an elementary
action is not executed synchronously in the order it is listed. Moreover,
this only occur when the target takes a specific value (the link itself).
The other problem is, now that the standard is published, if it is really
necessary to make a change in this area. I know I'm not part of WG12/SC29
but here is why I'm asking about this.
You perhaps know that the authoring tool I developed for CCETT is based on
Macromedia Director. I have to translate part of its scripting language.
When trying to translate nested if structure or case statements into MHEG-5
structures, you sometimes have to be aware of this kind of problems.
Suppose I want to translate this kind of statements in MHEG :
if anIntVar <> 0 then
if anIntVar = 1 then
action1
else
action2
end if
else
action0
end if
I would have to make 3 testEvent links but 2 would fire on the same event
(TestEvent from source anIntVar with data TRUE). So it is important for me
to be able to deactivate a link as soon as the author want.
Suppose a case statements with 10 choices ordered from the most likely to
occur to the less one. You can of course do the following
Activate(link for First choice)
TestVariable(Var, 1, First choice)
Deactivate(link for First choice)
Activate(link for second choice)
TestVariable(Var, 1, second choice)
Deactivate(link for second choice)
...
Activate(link for tenth choice)
TestVariable(Var, 1, tenth choice)
Deactivate(link for tenth choice)
But this would executes many useless action and activate, test, deactivate
many links even if the first choice was the right one.
That's why I think it could be proper to be able to have the following :
Activate(link for 1st choice true)
Activate(link for 1st choice false)
TestVariable(var, 1, 1st choice)
and then in link for 1st choice true
Deactivate(link for 1st choice true)
Deactivate(link for 1st choice false)
anything to do
and in link for 1st choice false
Deactivate(link for 1st choice true)
Deactivate(link for 1st choice false)
Activate(link for 2nd choice true)
Activate(link for 2nd choice false)
TestVariable(var, 1, 2nd choice)
But this second solution (that would work as any language would deal with a
case statements) only works if a link is able to deactivate itself
immediately.
Hope this clarify things;
Best regards,
__________________________________________________________________
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