Thank you for taking the initiative. I do think, some of the items
are quite important for clarifying.
> 1.2. SetData action
>
> Q. I would like to have the confirmation of the following mechanism. If
> content is initially
> included, and "setData" use a referenced content, the current content
> referenced by the
> variable parameter is copied in the content of the ingredient. Further
> changes to the content
> of the ingredient are not reflected to the variable used as parameter of the
> first setData
> action. Is this correct ? If content is initially referenced by a var (say
> var X) : If the setData
> parameter is an includedContent, this includedContent becomes the new value
> of var X. If
> the parameter is a referencedContent (referenced by var Y), the content of
> the ingredient is
> changed to var Y and var X remains unchanged (and is no more used by the
> ingredient) ?
> Is it correct ? Or in this last case, is it var X that remains the content of
> the ingredient and
> that is changed to a referencedContent var Y ?
>
> A. It is my understanding that the mechanisms described in the paragraph
> above are
> correct.
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().
> 2.MHEG-5 Integer range.
>
> Q. MHEG does not specify any range for Integers. This is legitimate in Math
> but not
> convenient for computers. Computers need to know if a number is a short,
> long, signed
> or unsigned. It seems that a signed long could fit, but MHEG-5 should be more
> specific
> in order to avoid interoperability problems.
>
> Also, once that range is specified, MHEG-5 should also specify what happens
> when an
> integer exceeds its range. For instance, if var 23 is the maximum integer
> value allowed,
> what is the effect of "Add(23, 1)" action ?
>
> A. The Range of Integer is not specified by MHEG-5. If a specific range is
> not to be
> exceeded in a given MHEG-5 engine, that engine shall deal with inapropriate
> values in its
> own way; it may for instance use engine events for that purpose (e.g. to send
> an error
> message). Similaryly, MHEG-5 does not specify the result an action resulting
> in a value
> out of range; here again engine events canbe used to signal the error.
The answer is OK. But I'd like to add the following statement, that
the range of MHEG-5 Integer shall be defined by the application domain
and the EngineEvent may be used for the purpose of overflow and
underflow during the math calculation.
> 3.MHEG-5 Stream Counter Position
>
> Q. MHEG-5 specifies the coding of counter position by an integer and also
> suggests to
> use DSM-CC protocol to encode the counter position within the stream.
> Nevertheless,
> DSM-CC specifies the position within a stream by using a couple of integers
> (the first one
> coding the seconds, and the second coding the milliseconds). Consequently,
> MHEG-5
> and DSM-CC seem incompatible on this point and DAVIC should be able to say
> how it
> plans to use the both in this specific case...
>
> Moreover, since MHEG-5 plans to use only one integer to code the counter
> position of a
> stream, it seems that it needs be 64 bits, which would be a heavy constraint
> on all other
> Integers for which one might assume that 16 or 32 bit be sufficient.
>
> A. ISSUE
DAVIC is compatible and in-line with MHEG-5 specs. The application
NPT represented using two integers doesn't mean we have to provide two
integers in MHEG-5. The reason why DSM-CC application NPT uses two
integers is that they like to fit application NPTs within 32 bits in
any case. So, as far as following the DAVIC, we have no mapping
problem here.
HOWEVER, as I discussed on this issue with some of you personally,
clearly we need 64 bits for the perfect mapping between the
application NPT and MHEG-5 integer. This is quite awful and I hate
it. But this is the problem of DAVIC and NOT THE PROBLEM OF MHEG-5.
Essentially, the application domain should take care of the precision
of MHEG-5 integer along with the CounterPosition. In this sense, I do
believe that the current DAVIC mapping definition 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.
> 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 ?
> May the noTokenActionSlot of right index be executed or is the callActionSlot
> action
> simply ignored ?
>
> If however it is not allowed (that is if the token can not be held by an
> unused cell), what is
> the effect of "move" and of "moveTo" action when the target cell is unused ?
> What is the
> effect of "scrollItems" action when it causes the cell that holds the token
> becoming unused
> ?
>
> A. Indeed, the standard dos not specify an y behaviour in such case. ISSUE.
> Opinions
> required!
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.
> Q. It seems that GetTextContent is rather to be used to get the
> objectReference of the
> variable that holds the content of the text while getTextData get directly
> the content of the
> text as an octetString. Nevertheless, a note says that if the content is
> included,
> getTextContent returns an OctetString. Does it mean then that
> "GetTextContent" and
> "GetTextData" are equivalent if the content attribute is included ?
>
> A. Yes. get TextData always returns the actual text octetstring, whereas
> getTextContent
> 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.
> 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
> EntryFieldFull
> 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
> reasonable
> 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
sense.
I hope my sentences help somehow.
Regards,
** Wataru KAMEYAMA, Graphics Communication Laboratories, JAPAN
** TEL: +81 3 5351 0181
** FAX: +81 3 5351 0185
** wak@gctech.co.jp ($B55;3!!>D!w#G#C#L(B in KANJI)