As Xavier tirelessly repeat, the question is : should MTF only make some
clarifications ? Or may it also suggest some technical changes ? (In fact,
is it possible for us to add some technical changes in MHEG-5 at this step
of standardization ?).
Since it seems important to be able to discriminate clarifications from
technical changes, how folks think we should do in such case ? We may say
it is a clarification if everybody agree about the interpretation of the
standard we make in the clarification. But, if someone disagree, if one
current engine or authoring tool implements this differently, can we say
that it's a clarification anyway ?
>> I understand that it could be contradictory to say in Visible activation
>> "display the Visible" if there is no content to display, but we could at
>> least interpret it as we want. For instance, an MHEG engine made for the
>> Internet could have deal with not available visible contents by showing a
>> rect or a broken icon or whatever, just like some other web solution allow
>> to do.
>
>Right, you can do this. But don't you agree that an author wants to have
>control over the layout? This is one advantage over HTML, I think it is
>very important to define (in MHEG-5 or in an ADD) how a Scene is displayed.
>It is not very consistent if one engine shows only empty rectangles and
>another engine waits for all the content before it starts displaying all
>the visibles.
Perhaps, but anyway, 2 engines can already render an application in very
different ways since they can define different application domains and
support only some classes, support scaling or not, cloning...
In any case, the interoperability cannot be ensured by MHEG alone.
>> Moreover, giving the responsability to the authors on this point is really
>> not convenient from an author point of view. MHEG don't provide sufficient
>> tools and flexibility for asking them to manage this. MHEG should at least
>
>Sorry, but imho it is the authors responsibility. The "convenience" must be
>provided by an authoring tool.
Easy answer ! How would you want an authoring tool to patch all MHEG
inconsistency ? Don't ask the impossible from an authoring tool or you
would get huge and unreadable MHEG application. The convenience on
contentAvailability cannot come from the authoring tool for instance, if
MHEG don't provide a getContentAvailabilityStatus function.
BTW, I think there are already sufficient thing to handle in a more
convenient way in an authoring tool (especially for ListGroup management)
but I don't know of another authoring tool than mine (MhegDitor) that try
to provide convenience in writing an MHEG application. Anyone ?
>> >For some people it might be a technical change, for others it is a
>> >clarification.
>>
>> If it is, Andreas, it means that it was not specified. Consequently,
>> specifying this IS a technical change, even if it agrees with the options
>> some may have taken before.
>
>No, it is a behaviour which was not correctly specified, it is not usable the
>way it is now (specified or not). By adding a note we clarify what were the
>thoughts and intentions of the WG12 during the time of the invention.
>We just forgot to do this in the first place.
So you seem to say that people that have work with MHEG until now should
have guessed the intentions of WG12, even if the standard specifications
were not sufficient. This doesn't really seem acceptable to me...
>> >Emmanuel:
>> >> 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... ?
>> >
>> >I hope the explanation helps. The important message is, that you can not
>> >always wait for the content to arrive, especially not in a broadcast
>> >environment. An engine can do other things in the mean time.
>>
>> I agree. So why not considering the same thing for the Activation behavior ?
>> Another proposal could be to make the IsRunning event asynchronous and
>> generated only when the content is available.
>
>This is an interesting idea. But how would you synchronize the whole Scene
>object. i.e. when is the IsRunning event of the Scene generated?
When all the initiallyActive ingredients of the scene would have generated
an IsRunning event.
>> >> (ListGroup)
>> >Engine constraints are always a problem but this definitly something the
>> >standard cannot deal with. This starts with memory constraints, speed,
>> >size of an Integer etc...
>> >I am afraid, this is an issue for an ADD, too...
>>
>> OK. I was talking about other constraints or rather provisions of use that
>> some engine may introduce. For instance, suppose a wrapAround ListGroup
>> with 3 cells and 5 items. What if an author make an action like
>> "setFirstItem(LG, 7)" ?
>
>Again, an error is an error is an error :-)
What do you mean ? Do you consider that my action is an error ? Or that the
engine implementation is an error ? IMHO, this action is not an error from
the author. MHEG doesn't specify any provision of use for NewFirstItem in
the SetFirstItem action description. Moreover, if you use scrollItems
beyond the last item with a wrapAround ListGroup, ItemsToScroll is simply
added to the FirstItem attribute. It is never said that the newFirstItem is
equal to (FirstItem + ItemsToScroll) mod (listSize). But it seems that some
engines act like that.
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