>> 1.2. SetData action
>No. Please refer to the 4th and 5th bullets of "the Privision of use"
>of the SetData(). It clearly says that NewContent encoding shall be
>matched with the current Content attribute, i.e. the OriginalContent
>attribute. Once you set the OriginalContent as included one, you have
>to always specify "included content" for any case by SetData().
Yes the answer of Wataru is correct.
>> 3.MHEG-5 Stream Counter Position
>> A. ISSUE
>DAVIC is compatible and in-line with MHEG-5 specs. ...should be changed
>somewhat like: the application NPT shall be mapped to MHEG-5
>CounterPosition in the precision of milliseconds and the microseconds
>shall be rounded up.
OK, this is a DAVIC issue, not a MHEG one.
>> 4.4. Token management in particular listGroup cases
>> Q. In some cases, like figures 8 or 9, some cells of the listGroup can remain
>> unused. Can
>> the token be held by an unused cell?
>> If so, what is the effect of a "callActionSlot" action when an unused cell
>> hold the token ?
>I think this is up to the application. Your application can make a
>cell position empty, or you can make sure that every cell is filled up
>with an Items. I don't think it's an issue here. The application
>should take care of the scrolling and manipulations of cells and
>items, and should be aware that what will be happened when
>CallActionSlot is called. As far as I remember, this is the
>discussion results in MHEG-5 IS Discussion Group. If you don't like
>to call an ActionSlot with empty cell, you may use EngineEvent to
>prevent that. But, again, it is up to the application domain, not the
>issue of MHEG-5.
Well, as I asked to Tom, I even don't see how action-slots can be applied
to cells since they are specified in the tokenGroupItems !!! (and remember
than the tokenGroupItems can be used to fill the itemList of the listGroup
but can be either empty). It would seem VERY CONFUSING for me that
action-slots could be defined next to items' visible references and applied
to cells, not
to items !!!!
>> A. Yes. get TextData always returns the actual text octetstring, whereas
>> returns either that octetstring -if the content is included- or a reference
>> to it -if the content
>> is referenced. Indeed in the case of included content the two actions return
>> the same: the
>> text octetstring.
>The last sentence is not correct. If it's the case of EntryField, the
>return value of GetTextData() and GetTextContent may be different
>depending on the modifications by users.
Right, the last precision seems correct to me, even if a bit confusing that
text holds to internal attributes like content and data. Content seems
superfluous for me when content is included...
>> 6.2. Behaviour when TextData is longer than maxLength
>> Q. An entryFieldFull event is generated when the entryField capacity is
>> reached (except if
>> it is the consequence of a SetData action). But in principle, the author is
>> not obliged to put
>> a link that sets the InteractionStatus to False when an EntryFieldFull event
>> is generated
>> and SetData can set the TextData attribute to an OctetString longer than
>> MaxLength. In this
>> case, when the user enters a new character, shall the interpreter generate an
>> event ? Answer could be "No, never", or "Yes, always" or "Only if the
>> entryPoint is
>> higher (or higher or equal to) than maxLength)"...
>> A. Very valid point. The standard does dot specify this point. (ISSUE?) A
>> interpretation is probably: Yes, Always, by definition of the EntryFieldFull
>> event, indeed
>> it is generated when the number of characters reaches MaxLength because of
>> user entry; it
>> turns out that there was already an excess of characters due to a SetData,
>> but it is only
>> generated now that a new entry is attempted.
>Your explanation is correct and I don't this it's issue. It's clear
>from the text. But it's worth to add this type of questions and
>answers to the FAQ.
>> Q. Is the EntryFieldFull event generated many times or only once? And what
>> happens to
>> that entry - is it taken into account or ignored?
>> A. Unspecified. (ISSUE?)
>Not an issue. You can take the EntryFieldFull event as a termination
>sign of the interaction. In this case, you just provide a link
>triggered by the event. Or, you can continue your input but you
>receive EntryFieldFull event along with your input. The standard says
>nothing about discarding the input when you receive EntryFieldFull.
>It means your engine shall continue receive user's input. Again, it's
>up to the application or the author how to handle the event and the
>EntryField interaction. MHEG-5 does provide a very flexible way to
>handle the EntryField and to control the input characters in this
OK, you're right, Wataru, but let's take the last example I gave to Tom and
he forwarded at the end of the techFAQ :
When the entryField is initialized to a string whose length is already
maxLength and entryPoint is 0 and overWrite is true. Characters entered by
the user simply replace default ones. The length of the textData is always
equal to maxLength when entryPoint is lower than maxLength.
In this particular case, shall the engine generate an entryFieldFull event
when entryPoint is lower than maxLength and that length remains unchanged
(but equal to maxLength) ?
In my opinion it should not except when entering the last char and that
entryPoint reaches maxLength. That way, it would provide a solution to the
example I gave but this behaviour is not specified in MHEG-5 and should be
issued I think.
Emmanuel BEUQUE Email: firstname.lastname@example.org
mediaServ tel: +33 (0) 2 99 64 36 64
Multimedia consultant & developer fax: +33 (0) 2 99 64 36 65