Thanks, but anyway, I have downloaded the Word97 converter for Word95 from
the Microsoft web site so I was already able to reopen your document. :-)
>Emmanuel:
>> ContentAvailable and Group IsRunning event.
>
>The problem with this event occures in an carousell environment when external
>content is not available at the same time the object prepares. Therefore, the
>praparation behaviour as it is written now says that the content is retrieved
>asynchronous. Otherwise, the preparation behaviour would block the whole
>engine. The question is now, what happens if an object is activated and
>the content is yet not available? Therefore, the asynchronous ContentAvailable
>event is synchronised with the Activation behaviour, i.e. the behaviour
>blocks if the content for the object is not available.
>
>It is the authors responsibilty to activate an object with external content
>only if the ContentAvailable event for this content has been raised.
>This is very important in a broadcast environment.
>
>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).
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.
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
provide a "getContentAvailabilityStatus" function if we want to do this.
Moreover, this kind of requirement would need a lot of procedural code such
as Links or advanced tips to solve this problem. This would just make MHEG
scenes less compact and show the worst side of MHEG IMHO.
>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.
>
>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.
>> 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.
>
>Oh, I think that the standard doesn't prevent an author from creating an
>MHEG-5 application which breaks every engine, it just takes a Scene and two
>Link objects.
>The standard can not handle every situation. So, imho a lot of responsiblity
>lies at the authors side.
>When an author is aware of a problemematic situation and doesn't handle it
>then it is an authoring error. The note should give a hint to authors that
>this part might cause problems.
As you said, this is not a problem when an author is aware of the problem.
It's true that an author could deliberately do something that breaks
engines with pretty any tool or standard. What I mean is that the author
could be aware of some problematic situation but we cannot ask any MHEG
authors to always keep in mind some problems that we, experts, have made
more than a year to clarify or solve.
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.
Consequently, I just wanted that we keep in mind that the problem that
could be solved in the standard, should be solved. Otherwise, the standard
would less likely to be used since there could be other more convenient
solutions.
>Emmanuel:
>> (ListGroup)
>> 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.
>
>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)" ?
Suppose a not wrapAround ListGroup with 5 cells and 3 items. What if an
author make an action like "setFirstItem(LG, 0) ? Is it possible to display
the items in cells 2 to 4 ?
The same goes for scrollItems. Also, the FirstItem should be interpreted
modulo the size of the list IMHO. But should it keep its original value or
its modulo value ? For instance, in my first example (WrapAround, 3 cells,
5 items, setFirstItem(LG, 7)), suppose we evaluate the GetFirstItem(LG)
function. Should it return 7 or 2 ?
>Emmanuel:
>> 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 ?
>
>Andy?
Yes, certainly one more thing to clarify in Andy proposal for ListGroups...
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