Well, I see what you mean Klaus. I think all depend on the point of view we
adopt, that is :
Is it the setInteractionStatus action that should generate an
InteractionCompleted event (my opinion) ?
OR
Is it the interactionCompleted event (generated by the MHEG engine and
implementation depending) that could be used by the author to fire a link
that set the interaction status to FALSE (I think that is your opinion) ?
Let me explain a bit more. I think you focused too much on the EntryField
class, which is not the only subclass of Interactible...
If we follow the class hierarchy, and try to understand
InteractionCompleted event, just read section 41.2 about this event. It
says "it is generated only when the InteractionStatus internal attribute
returns to FALSE after an interaction". That's why I understand that the
interactionCompleted event is the consequence of the setInteractionStatus
action.
Consequently, I think that an author must avoid using a
setInteractionStatus to False action within an InteractionCompleted link or
the engine would run into an infinite loop.
Concerning the EntryField, the standard tends to say that the
interactionStatus shall be set to False by the engine on itself (when the
user terminates the entry) and, consequently, the engine should also
generates an interactionCompleted event. (So the author do not have to
provide any mechanism to terminate an entry but this mechanism is
implementation depending).
What I find unclear there, is that the standard also speak about "or
because the application terminates it using the SetInteractionStatus
action". I think this part of the clause should definitely be removed
because it is redundant with the definition of the setInteractionStatus
action.
>> >here is another technical question, this time about the Interaction
>> >Status.
>> >
>> >It is written in 41.1 2c in case of a
>>
>> I think it's rather in 41.4 2c for others.
>
>oppps. Yes. But no problem for the experts, right? :-)
>
>
>> >SetInteractionStatus(false) action:
>> >"...generate the InteractionCompleted Event"
>> >How about removing this sentence?
>> >Reason: For example, you have an Entryfield, which is interactible. With
>> >some means the user terminates this interaction, I would expect the
>> >Entryfield to generate a IteractionCompleted Event on it's own.
>> Here my question is : how (with which means) will the user terminates the
>> interaction ? I think this is the source of your question.
>
>No. This is another interesting question. In our implementation you have
>to use a sepcific key to do that (e.g. the "ok" for a Remote Control, or
>the "tab" for keyboards (just like Windows is doing)). This is
>implementation depending, and might be subject for a profile.
>
OK, you are right and that's what should be clarified a bit more in 53.5 IMHO
>
>> > This
>> >event will be used by a friedly MHEG app to fire a link which sets the
>> >Interaction Status to false (which is the only way to change the
>> >interaction status). A second "interaction completed" it not that good.
>> In my understanding, with a platform that do not handle unspecified tasks
>> or events, I would expect that when the user have finished to enter chars
>> in the entryField, it terminates the entry with a specific userInput event
>> Then this userInput event could fire a link the set the interaction status
>> to false and generates (but only once) the interactionCompleted event.
>
>This is explicitly forbidden, since the "interacting" Entryfields
>catches all the user input events. See the section 53.5.
>Reason for this is, that one might wnat to use the RemoteControl keys to
>enter characters, e.g. with the up/down changing the character, and the
>left/right to change the position. This is an abstraction level for the
>application programmer.
OK, you are completely right here, I would rather have said an
"EngineEvent" to terminate the entry, but as we could interpret the
paragraph 43.3 4, it's rather the platform that should provide the way to
terminate the entry, and it is not the responsability of the author, right ?
>> All
>> the same, an EntryFieldFull event could fire another link that also set the
>> interactionStatus to false.
>
>This can be done, but this does not work when the entryfield is simply
>not full.
>
No, this is only an additionnal link which make possible for the
application itself to terminate the entry, am I right ?
>
>> IMHO, it is rather the whole paragraph 43.3 4 which is confusing or should
>> be either removed or explained. What does it mean by "because the user
>> terminates the entry" ? It isn't said anything on how the user is supposed
>> to terminates the entry here or I perhaps missed something.
>
>It's up to the implementation, I think, since we can not foresee the
>available keys on the remote or keyboard.
>
See my comments above about application responsability which is redundant.
>
>> >Main issue behind: Who is in charge to generate the InteractionCompleted
>> >event? We suggest that it is comming from the EntryField object itself.
>> All can be discussed. I'm usually opened to all necessary changes,
>> especially when it allows to make things clearer for everybody.
>
>At least it should be clarified.
>My clarification would be to write somewhere: "It is in the
>responsibility of the Interactible object to generate the Interaction
>Completed Event, when the user has indicated that the interaction is
>completed by an implemenation depending mechanism."
>
Well, as explained above, I think the InteractionCompleted event shall be
generated as a consequence of setting the interactionStatus to False. This
is used for Sliders, HyperTexts and EntryFields (button do not have
interaction behaviour) where the engine should terminates the interaction
by itself (though I personnally think this is not useful for sliders at
least).
So, my suggestion is rather to remove the clauses about application setting
the interaction status in EntryField (43.3 4) and HyperText (44.3 3) that
make redundancy.
>
>> >Additionally: In the same paragraph, it is missing that the interaction
>> >status should be set to false, if a appropriate action is executed.
>> I agree.
>
>I think this is obvious.
>We should make up a list of issues for the upcoming Stockholm meeting.
>SC29WG12 might want to see a list of things, in order to judge about a
>amendment process.
Do you better understand my opinion now ?
Kind regards,
Emmanuel
__________________________________________________________________
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