here are some words about the MHEG-5 corrigendum, which is out now
officially, and which is available at http://www.mheg.org. The shorthand
name is DCOR1. I am going to use that nickname to refer to the doc.
We'll plan to mirror it at the MUG next week, including some other stuff
related to MHEG-7 from the recent SC29WG12 Saariselka meeting.
The document is based on the comments on the MHEG-5 text from the MUG
and from the ISO. If you remember, we have had a long list of issues
which came up during implementation and interworking tests of MHEG
systems. Most of the problems have been due to unclear text and to
contradiction. Some of the raised issues have been due to requests for
new functionality. However, as with all standard technical corrigenda,
the DCOR shall not add functionality, it should only repair what is
required and preserve the spirit of the original text.
Due to that existing implementations will not be broken, except they
have followed a wrong interpretation of the original text. The MHEG-5
Maintainance Task Force has spend a lot time and efford to come to a
conclusion which is the correct interpretation. This process was quite
painful due to the restrictions of the content of a technical
corrigendum. Nevertheless, since we have had the experience of at least
6 different MHEG system developments on the table, AND we have had also
Andreas Kraft, who was very strict in favor of the ISO editing rules, I
am confident that the extract of all the discussions meets not only the
law, but also the opinion of the group. I should point out that all
decisions have been made unanimously. Due to that I do not expect much
opposition nor strong resistance for the text at ballot time.
Nevertheless, here are some comments on the text:
The structure of the text follows the class definitions. The interesting
text starts with clause 5. Clause 32 and 33 deals with the annexes and
clause 34 deals with the remainings.
Each clause consists of editing instructions. Please note that ISO will
NOT deliver a changed complete text. That is a bit unfortunate, but this
is also ISO law. But this procedure has worked for other successful
standards as well, e.g. MPEG.
The clauses do not refer to the original Issue-Index from the MUG, the
DCOR is a stand-alone document.
Most of the text does "only" fix obvious typos and contradictions, or
provides clarification. The following is a list of significant cases
which I think may have impact on implementations or application design:
* Clauses 7.3 and 6.1: On-Startup can not have TransitionTo, Launch...
That may be a suprise for some of us (including me). But technically
it is obvious: The OnStartup actions are meant to be executed BEFORE THE
PREPARATION of the items of the respective group. Therefore, it is a
handle for very specific cases, and should not be used for context
changes. If you do it, you will surely end up in an unstable situation,
since you can NOT use any of the ingredient of the group in startup,
except you prepare them by hand.
The DCOR helps not to come into this situation. It is not a technical
change, it is an aid not to produce wrong applications.
To achieve execution of actions after all Items are prepared you may
simple use a self-triggering link like that:
{:Link 1 :EventSource 1 :EventType IsRunning (:TransitionTo("s" 0))}
* Clause 9.3: Preload is now allowed for Items without content
This is the removal of a provision of use, which disallows Preload
on Hotspots and Rectangles. This clause is a preservation of the spirit
of MHEG-5: It was simply forgotten that :Preload does not only loads
content, it also prepares an object, and puts it into the stackingorder
when there is no content.
Most of the implementations have ignored that provision of use anyway.
We have delveloped a longer text to explain that clause, which I am
publishing next week. This was required since there was a official NB
comment requesting that the provision of use should stay. But the
situation was resolved.
* Clause 9.5, 15.1: SetData causes ContentAvailable
This is a clarification, since it was said before that arrival of new
content raises a ContentAvailable event. That is now more clearly
stated, and it is also very much required in a ObjectCaroussel
situation, where content may really be delayed. As long as SetData is
asynchrounous and delivers new content, a ContentAvailable event is due.
* Clauses 16, 17: TokenGroup, ListGroup
Well, this is heavy. The listgroup and the tokengroup are late-commers
in the standardisation process, and they have been full of ambiguities.
Due to that we have a completely revised text, and a new example in the
annex. Nevertheless, the text is conservative. The only real
modification is the event order in case of preparation.
* Clause 22.4: SetData on Streams now allowed
Please note this one. During development of MHEG-5 there was no common
opinion what to do with Stream and Counter Events in case of SetData on
Streams. The solution was to forbid it. That was from todays point of
view a bit short-thinking...
Due to that it is according to MHEG-5 required to have N stream objects
in case of a VdD app which allows to select between N videos, instead of
a SetData and a single Stream. This makes engines difficult to develop,
since most often a Stream decoder device is mapped to a Stream Object.
Due to that the general opinion was to allow the setData on streams.
However, this option was not choosen without controversion. It was added
to the DCOR with the argument, that NB comments can ask for removal of
this clause, and that such comments will be taken very serious. So, we
have now some time to think about it. It is close to a technical change,
so please consider that clause carefully.
* clause 34.1, 34.7, 34.8: Definition of none, null, etc
The MHEG-5 text uses sometimes the term "null object reference".
However, it was not defined how to encode such a object reference, and
due to that it was impossible to compare results of actions against such
a null reference. The definition was added in the DCOR. This has impact
on implementations, since Apps may use that feature now. However, most
of the implementation have already defined such special values, and now
it is official.
Ok, thats the comments for today. I am going to release some more text
from Saariselka next week. Find below the IOS note of publication for
yur reference in case you want to contact you NB due to the DCOR.
Bye,
- Klaus
Official ISO release note
01. Committee designator: 29
02. Numeric Document number: 2567
03. Backward pointer: --
04. Document type: Text for DCOR ballot
05. Date: 1998-05-07
06. Document title: ISO/IEC 13522-5/DCOR 1, Information
technology -- Coding of multimedia
and hypermedia information -- Part 5:
Support for base-level interactive
applications, TECHNICAL CORRIGENDUM 1
07. Due date: 1998-08-21
08. Number of pages: N/A
09. Source: Project Editor
10. Project number: JTC 1.29.06.05/COR1 (13522-1/COR1)
11. Status: In accordance with Resolutions 1 and
10 taken at the thirty-first SC 29/
WG 12 Meeting, 1998-04-20/22,
Saariselk, Finland, the SC 29
Secretariat has issued DCOR ballot,
and inform the JTC 1 Secretariat and
ITU-T of this ballot.
12. Action identifier: LB
13. File size (KB): 543.8 (except isoiec.gif)
14. Language used: English
15. Diskette number: 29D223
Issue serial number: 29F133
File name(s): isoiec.gif, 29n2567c.htm,
29n25671.pdf (=29n25671.doc),
29n2567b.txt
Requested Action: For ballot by SC 29 P-members
16. Document access level: Def
-- GMD FOKUS German National Research Center for Information Technology Klaus Hofrichter Kaiserin-Augusta-Allee 31 D-10589 Berlin Germany mailto:hofrichter@fokus.gmd.de http://www.fokus.gmd.de/usr/hofrichter P: +49 30 3463 7211 Fx -8211 There is a reexamination, but no reparty