I am also posting an html version of this on my site:
(http://www.mheg.com/projs/mheg/techFAQ.html) where I will keep it up to
date.
Regards,
Tom
------------------------------
MHEG-5 Technical FAQ
--- Last update: Friday, January 30th, 1995. ---
--- Maintained by Tom Schwengler (tschwen@uswest.com )
--- and the MHEG User group.
The following is a list of tricky points, or ambiguities in the ISO/IEC
13522-5 (MHEG-5)
standard. Some answers are provided. Feel free to contact me for additional
information
or comments.
1. MHEG-5 Ingredient Content
1.1. Content and OriginalContent attributes
Q. The ingredient OriginalContent attribute can be either included or
referenced. Is this
initial state (included or referenced) definite? In other words, is the
internal attribute
Content of the same type?
A. Yes. The state of an ingredient Content (included or referenced) is fixed
by the
InitialContent attribute.
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.
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.
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
4. MHEG-5 List Group Class
4.1 TokenGroup inheritance
The ListGroup class inherits from the TokenGroup class but some mechanisms
managed
by the TokenGroup (or TokenManager) behaviours remain unclear due to the fact
that the
number of cells is generally not equal to the number of items in a ListGroup.
Q. Section "30.1.2. Positions" of MHEG explains the relationship between
cells and
TokenMovementTable. This seems to imply that the token movement table (and
consequently the move action) are applied to cells. Is it also true for
"moveTo" action ,
"tokenMovedTo" and "tokenMovedFrom" events? (do they all relate to cells as
well?)
A. Yes. The confusion may come from the fact that the TokenManager class
defines
"Items" that are later - in the ListGroup class- referred to as "Cells". In
turns ListGroup
defines "Items" that are Visibles that can be displayed in these "Cells". In
other words the
term "Item" used in TokenGroup and TokenManager corresponds to the term
"Cell" in
ListGroup. (The text of the standard is rather confusing in that respect). To
clarify: in the
ListGroup class, all actions and events that are inherited from the
TokenGroup or
TokenManager class relate to cells: that includes Move, MoveTo,
GetTokenPosition (and
related Token events), but also CallActionSlot (see Q 4.2). The other actions
(Select,
DeSelect, AddItem, DelItem...) relate to the ListGroup "Items", that is to
the actual
Visibles of the ListGroup.
4.2. Action-slots
Q. Is the mechanism of action-slots authorized in the listGroup class? If
true, is the
tokenGroupItems (initial state) the only way to define action-slots for items
(since
"addItem" provides no solution to define action-slots for the a new item...)
?
A. Yes, ActionSlot are obviously allowed in ListGroup. Indeed there is no way
to attach
an ActionSlot to a new Item for the simple reason that -as explained in 4.1,
ActionSlots
are attached to ListGroup cells, not to its Items.
Q. The standard reads (section 29.4): "CallActionSlot" executes an action
object
associated with the item that currently has the token. But for listGroup the
token is based
on cells not on items - I am confused.
A. In a LisGroups, CallActionSlot and Token activity is indeed based on
cells, not on
Items.
Q. By the way, it seems that MHEG-5 IS contains a mistake in the provisions
of use for
callActionSlot action at section 29.4 : Mheg says "Index shall be set in the
range [0,
number of items in the tokenGroupItem]" though index here has nothing to do
with the
position of the item in the tokenGroup but rather with the position of the
actionSlot to do
in the sequence of actionSlots... So the range shall rather be [0, number of
actionSlots for
the item that currently holds the token] but I'm even not sure that is
required. Indeed, in
my opinion, if the index specified has no corresponding actionSlot, the
actionSlot could
be considered as "null" and the callActionSlot shall be aborted.
A. Correct. There is a mistake in the MHEG-5 IS. It is on the list of
editorial changes to
make before publication. Regarding the necessity of this provision of use, it
may indeed
not be needed; however it seems useful to mention it. And when the Index
exceeds the
limit, it is an error which results in ignoring the action anyway .
Q. What is the effect of "delItem" for actionSlots ? Is the actionSlot
deleted with the
Vsible item?
No. ActionSlots remain in their cells, even if a visible is deleted there.
4.3. Use of the listGroup class
Q. If "tokenMovedTo" and "tokenMovedFrom" events are based on the cells, how
could
a link be built in order to do something when an item holds the token (that
is when the
item is displayed in the cell that holds the token) ?
For instance, suppose that an application developper needs to select the item
that currently
holds the token. What is the simplest solution to do that?
A. Keep in mind that there are two mecanisms of selection: Tokens (attached
to cells) and
Select/DeselecItem (attached to Visibles in these celles). In the example
above, the use of
SelectItem and the corresponding GetItemStatus may be the best to use,
without any need
for Token. If however, for any reason, it is preferred to use Tokens, here is
the way to
proceed: use GetTokenPosition to get the index of the cell which currently
holds the
Token. Then you may either use GetCellItem to obtain directly the reference
of the visible
attached to that cell. Or, if you need to use the SelectItem action, add it
to GetFirstItem -1
to obtain the index of the item with the Token.
(Granted that the latter is a cumbersome process, and a "getCellItemIndex"
action that
could give directly the index of the item which is displayed in a specific
cell may have
been more convenient... However it was not done.)
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!
5. Text class
5.1. GetTextContent versus GetTextData
Q. What is the difference between "getTextContent" and "getTextData" actions
?
A. The text class has two interesting internal attributes: Content and
TextData. In short
getTextContent returns the value of the Content attribute, and getTextData
returns the
value of the TextData attribute.
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.
6. EntryField class
6.1. Interaction internal behaviour
Q. In section "43.3. Interaction.2 and 3", characters entered by the user are
used to update
and change the content of the "TextData" attribute. If the content of the
entryField is a
referencedContent (referenced by a variable X), shall the content of the that
variable be
also modified or not ? If not, this means that the result of getTextContent
may be different
than the TextData : is that right ?
A. Modifying an Entryfield (by interaction) results only in the modification
of the
TextData attribute. In the case of referenced content, the referenced
variable shall not be
modified, and indeed the Content referenced by getTextContent may be
different from
TextData. (The application developper can insure that such difference never
happens, if he
so wishes, by always appending a SetData action to the referenced content
after an
interaction).
Q. Section "43.3.Interaction.4" reads: "When the entry is complete (either
because the
user termitates the entry or because the maximum number of characters has
been entered,
...". How can the user terminate the entry ? (since EntryField full no longer
sets the
EntryField InteractionStatus to false in IS but generate an event instead.
A. As mentioned in section 43.1.2, in that case the MHEG-5 engine shall
provide the user
with some mean of terminating the interaction. The user uses that "mean"
(e.g. a specific
button on aremote control), which in turns generates the InteractionCompleted
event.
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.
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?)
The following example may illustrate better the reason for these questions.
An MHEG-5
application proposes to program something (perhaps a VCR) based on a date and
time
event. The user has to fill the date and time in some entryFields (1 for the
day, 1 for the
month, etc...). But the author wants to fill the fields with the current date
and time for
default values (as all VCR do). Suppose we are the 27th day of the month, the
initial
textData will be "27" and maxLength is set to 2, overwrite is set to True and
the
entryPoint is 0. Is there a way in MHEG-5 to make the InteractionStatus False
and go to
the month entryField when the user has entered 2 chars (EntryPoint is at
2)...?
This particular example illustrates the problem well - such examples to
explain some
MHEG-5 mechanisms are deeply needed and missing in the text (even if MHEG-5
is well
written in general). In this particular case, in my opinion, it would be
better to generate an
entryFieldFull event when the entryPoint changes and is equal to (or higher
than)
maxLength. Also, it could have been interesting to define that the length of
TextData can
not be longer than MaxLength (excepting maxLength = 0) and to cut
automatically
superfluous characters.
__________________________________________________________________
Acknowlegements
Many thanks to Emmanuel BEUQUE, Multimedia consultant & developer, for
initiating
this list.
__________________________________________________________________