As you said, there were only implementors of engines, not of authoring
tool. That's why I regret I could not come because I'm convinced that you
could make something that is clear for an engine implementation but that
makes MHEG not really usable for some applications.
>One very important thing which I think you may underestimate sometimes
>is the "ease of use of MHEG". Frankly speaking, there is NONE. Moreover,
>there is no intention to have some.
That's definitely a problem IMHO. I understand what you try to explain,
Klaus, but I don't fully agree with you on this (see below).
>MHEG is targeted to low resource systems, it should be called Multimedia
>Assember or Multimedia Postscript. So, there is not convenient MHEG
>language feature. That is up to the authoring tool. It is like Visual
>Basic and pentium assember.
OK, I see what you mean but it's not completely true IMHO. Just let me take
an example. The ListGroup class defines a "GetCellItem" elementary action.
This action is not needed in low-level only description language. We could
obtain the same information with a combination of "GetListItem",
"GetFirstItem" and "GetTokenPosition".
The same goes for "ToggleItem". "SelectItem" and "DeselectItem" would have
been sufficient. These two actions are clearly provided for ease of use,
aren't they? I'm sure we could find other examples like these in MHEG.
On the contrary, there is sometimes a lack of low-level actions. If MHEG
was really low-level, we should be able to get all class attributes with an
action and to set most of them. Once more, this is not the case. For
instance, we cannot get the ContentAvailability status.
In connection with that, MHEG sometimes does not provide a way to simply
have an object in a state that is required by provision of use of some
actions. For instance, there is no way to make Ingredients
initiallyAvailable but not initiallyActive. This kind of limitations
sometimes makes authoring an application with no error simply impossible.
To patch this kind of problems, some actions provide some automatic test
before calling the corresponding behaviour, but unfortunately that's not
the case of all. MHEG is simply not consistent in this area.
For instance, you can target a Run action on an already active presentable.
The action will be simply disregarded. But you are not allowed to preload
an Ingredient that is already available. Could you tell me why ?
If an authoring tool must handle all the cases with conditional link that
preload an ingredient only if its availabilityStatus is false, The MHEG
application would require one more boolean variable and one more link, and
the scene would simply be 3 times bigger than what it could.
Consequently, I would simply like to say that you, MHEG designers and
engine implementors, cannot consider that some problems are from the
responsability of authors or authoring tool because MHEG sometimes simply
doesn't provide the possibility to handle them correctly.
I regret there don't seem to be many application authors on the MUG list.
If any, please give your opinion.
BR,
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