I would like to give my opinion on the doc related to the MTF meeting that
occured in Berlin in last 12/13 February.
First, let me give a suggestion about the format of the documents posted on
MTF site.
As old version of Word are usually unable to read new doc formats without
downloading a huge converter from MS web site,
As new version of Word are sometimes (and more unexpectedly :-( ) unable to
read an old document format (see DSM-CC/MHEG-5 doc with Word 97),
And finally as many documents don't use more features that the one defined
in pretty old formats,
I suggest to post documents in a more standard form : HTML is fine but if
it is too difficult to generate properly, why not RTF or PDF files ?
Regarding the 1074 document, I have the following remarks :
ContentAvailable and Group IsRunning event.
The doc stated that MTF want to add a note in 9.3 saying that all
ingredients have their content available when the group isRunning event is
generated.
I understand that this would be interesting for some of you since it should
simplify things but it seems to introduce a contradiction where there
wasn't one before. IsRunning is a synchronous event while ContentAvailable
is an asynchronous one. I definitely don't see how a synchronous event may
occur after some asynchronous ones.
In order to do this, MTF wants to redefine the activation behaviour of the
Root class. Heavy change at this step of standardization IMHO. Moreover, I
do have the feeling that we go round in circles.
MHEG-5 DIS only had an IsAvailable event that has been separated in 2
different events IsAvailable and ContentAvailable. Today, it seems we want
to join them again. Could someone explain me why it was decided to separate
the events for IS... ?
Preload, Unload
It seems nice, great, to me that Unload and Preload can be targeted to
object without content. This seems essential to me since many objects
(rectangle, link, etc...) must be prepared before being targeted an action
and you often don't want to activate it in order to be able to do this.
Here, it seems that these actions were initially provided to prepare the
content while in fact we need something to make an object available to fit
many actions' provisions of use.
Regarding Issue 7:
It is said : "It is an authoring error not to handle this situation properly".
I don't like this attitude. To me, when MHEG just sets a trap to authors,
it is just less likely to be used in the future.
Regarding Issue 8 (setData on streams) :
I agree that all attributes shall be resetted to the original values.
The second sentence (All pending counter triggers are removed) seems
confusing to me. First, it is necessarily the case if attributes are all
resetted. Secondly, why does MTF say "pending", why not simply all counter
triggers ?
This makes me think that people may have different opinions on how to
handle counterTriggers and a clarification is perhaps needed there.
When a counterTrigger event is generated, shall this trigger be removed or
kept from the CounterTriggers sequence ? Suppose a looping stream, and a
counterTrigger set only once, shall the counterTrigger event be generated
at each loop or only the first time ?
The fourth point (Clarification : The number of MHEG stream components can
not change) would rather be "The number *and type* of stream components. It
seems important to me that the new stream content is of the exact same type
in terms of multiplex components as the initial one.
Moreover, MTF wants to let the application domain specify how to deal with
encoded substreams. I think we should at least advise to reuse the same
componentTag in the new stream.
Regarding clarification for 37.1.2.
The term "clarification" seems funny to me since there is no clarification
but MTF simply lets the application domain deal with this problem. Again, I
think that we should suggest to use the componentTag attribute of the
stream components to assign substreams to objects in the multiplex content.
Issue 36: lineOrientation.
Again, this is not a clarification but a workaround. This seems really bad
to me. There are still so many things that depends on the application
domain that this kind of basic description should definitely be clarified
in MHEG-5.
Especially when it is said in MHEG that "these attributes may be ignored"...
Issue 11:
The note to be added at 14.4 could be clearer IMHO, by specifying when a
variable is passed as a reference or as a value. To me, if the indirect
reference option is used, it is the value contained in the variable that is
passed to the program. But a program may rather need to get the objectRef
of the variable itself in order to use it for In and Out. In that case, the
indirect reference may be ignored.
I have noted that a proposal of clarifications is expected by Andy on
ListGroup issues. I think this is essential since the ListGroup is one of
the most interesting class of MHEG.
I think that there are even some other issues not listed currently.
For instance, there is no provision in MHEG about the possible values for
the FirstItem attribute. The figures in the standard even suggest that it
may take any value. However, it seems that some engines introduce some
constraints about it.
SetFirstItem action provides no provision of use on the newFirstItem argument.
ScrollItems neither. But MHEG don't say anything about the case FirstItem
is 0 or even negative. We should also clarify what occurs when FirstItem is
greater than the list size (when WrapAround is either False or True).
How do you all have dealt with these cases ?
I expect many more clarifications from the MTF.
Best 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