On Fri, 20 Feb 1998, Emmanuel BEUQUE wrote:
> À (At) 17:31 +0100 19/02/98, Andreas Kraft écrivait (wrote) :
> >I think that these things are not very clear by reading the standard.
> >You can already interpret the standard in this part at least two different
> >ways.
>
> That's why I don't agree with you on this point and why Guillaume and me
> think it is a technical change (moreover low level one).
A clarification is not a technical change.
However, to say what is a technical change and what is a clarification
is very important. Please keep in mind that we want to propagate the
changes (whether they are clarifications or technical ones) as fast as
possible.
> 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.
> 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.
> >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.
Concerning technical changes, we will have to apply some of them. For example,
without the addition of an Activation behaviour, the Variables are useless.
> >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?
> >> 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.
>
> What I said it that it is an easy reaction, when being confronted to a
> problem, to say that the problem should be solved by the other persons
> involved in the process. It's just a bad attitude IMHO. If everybody was
> doing like this, just nothing could work today.
Don't understand me wrong. I don't want to point a finger to somebody else
and reassign the responsibility or work. It is hard to find the line where
one responsibility starts and the other ends.
MHEG-5 solves some problems and leaves others open which must be solved by
ADD's. This causes confusion in some parts but also allows for quite some
flexibility.
> >Emmanuel:
> >> (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 :-)
Regards,
Andreas
-- o _ Andreas Kraft (\_|_) GMD FOKUS, kraft@fokus.gmd.de, +49 30 3463-7232 T> ] [ The sky is the limit