Let me cite some of the most relevant messages extracted from the
discussion that took place on the IS task force reflector during the
second half of September 96.
After an already long mail discussion, I re-explained the whole proposal
made and agreed at Tampere. This is MESSAGE 1 below.
See then the only two responses to this message, from
Klaus (MESSAGE 2) and Tom (MESSAGE 3).
To make sure everyone had a change to express their position,
Tom then made an enquiry (MESSAGE 4) whose result was
to confirm the motion (MESSAGE 5). Message 5 was the
last message on the issue.
Hope this helps to clarify the issue. Using this reminder as the help,
I hope WG12 members that took part in the IS task force will be able
to give Christine a documented answer.
Officially, WG12 is in charge of the maintenance and interpretation of
the standard. I think this is a good test to see whether the MHEG
Users Group can more informally play this role by leveraging upon
the knowledge of its WG12 experts through e-mail participation.
Best regards
Xavier Marie
----------MESSAGE 1
De : Xavier MARIE[SMTP:graal!xavier.marie]
Date d'envoi : mardi 17 septembre 1996 18:21
A : mheg5is@fokus.gmd.de
Objet : Re: Call/Fork
Dear Colleagues,
Klaus wrote:
> Xavier wrote:
> >...
> >MHEG-6 will specify that use of
> >OutParameters is prohibited with InterchangedProgram.
> >...
> From encoding point of view, this would work, but from the semantics of
> MHEG-5 the difference is, that in the case, where we have distinction
> between in and out parameter, the in-parameter are not expected to be
> changed by call/fork.
1) I don't see the use for this distinction. My view is:
a) if the parameter resolves to a value (e.g. GenericBoolean), then it is
naturally to be taken as an IN parameter passed by value. There is no way for the
called program to change it durably anyway.
b) if the parameter resolves to an object reference to a Variable
(e.g. GenericObjectReference to a BooleanVariable), then it is
naturally to be taken as an INOUT parameter passed by reference. The
called program can change it using any mechanism. For MHEG-6
InterchangedProgram the mechanism is to use the MHEG-5 API
SetVariable operation. For other kinds of programs the mechanism is
application domain or implementation-dependent.
> Therefore, the MHEG-5 API may not allow to set the
> in-parameter.
2) As mentioned above, there is no point like that. If the parameter is
a value, it can't be set anyway. If the parameter is a variable, it
can be set as any other variable can. There is no data protection
mechanism in MHEG, so any variable can be set any time by any object
within scope.
> I'd prefer to have a clarified text in MHEG-5, which is
> not in conflict with MHEG-6 provisions.
3) I'd prefer as well. That's why we're having this discussion.
> My suggestion is now to have a distinction between pure in variables,
> and in/out variables. The encoding would be as Robert proposed, perhaps
> with the renaming of out-parameter to inout-parameter. In this
> case, MHEG 6 would be able to specify to use ONLY InOut (i.e. "call by
> reference"), and other domains may be able to optimize their runtime
> behavior by using the in-parameter ("Call by Value"), whose value can
> not be changed by the call/fork. This distinction my be useful in
> particular when using the fork, which is asynchron.
4) Again, I think there is a global misunderstanding. MHEG-6 would specify to
use ONLY IN. That's indeed because of the fork, and because of 1)
above.
Xavier
---------------------------------
Dr Xavier Marie
tel: +33 99 38 43 43
fax: +33 99 38 40 78
e-mail: Xavier.Marie@cril-ing.fr
---------------------------------
----------MESSAGE2
De : Klaus Hofrichter[SMTP:graal!fokus.gmd.de!hofrichter]
Date d'envoi : mercredi 18 septembre 1996 09:34
A : graal!Xavier.Marie
Cc : mheg5is@fokus.gmd.de
Objet : Re: Call/Fork
Folks,
Xavier explained (once more) his point of view on Call/Fork:
> ...
> a) if the parameter resolves to a value (e.g. GenericBoolean), then it is
> naturally to be taken as an IN parameter passed by value. There is no way for the
> called program to change it durably anyway.
> b) if the parameter resolves to an object reference to a Variable
> (e.g. GenericObjectReference to a BooleanVariable), then it is
> naturally to be taken as an INOUT parameter passed by reference.
> ...
> If the parameter is
> a value, it can't be set anyway. If the parameter is a variable, it
> can be set as any other variable can. There is no data protection
> mechanism in MHEG, so any variable can be set any time by any object
> within scope.
In this sense, I agree with Xavier. Another advantage is: The encoding
is much simpler, since there is only one list of parameters (but this
last thing is purly driven by our actual implementation).
- Klaus
-- GMD FOKUS German National Research Center for Information Technology Klaus Hofrichter Hardenbergplatz 2 D-10623 Berlin Germany mailto:hofrichter@fokus.gmd.de http://www.fokus.gmd.de/usr/hofrichter Tel +49 30 25499-211 Fax -202 There is a reexamination, but no reparty
----------MESSAGE 3 De : Tom Schwengler[SMTP:graal!advtech.uswest.com!tschwen] Date d'envoi : mercredi 18 septembre 1996 13:21 A : mheg5is@fokus.gmd.de Objet : Re: Call/Fork
Reply to: RE>>Call/Fork
I like that position (below) as well. It was what I was trying to explain in one of my previous messages. It also hass the (small) merit not to change anything in annex A or B as they are now. I will add aclarifying sentence in the call/fork soecification in that sense. Regards, Tom --------------------------------------
Xavier explained (once more) his point of view on Call/Fork:
> (...)
----------MESSAGE 5 (includes message 4) De : Tom Schwengler[SMTP:graal!advtech.uswest.com!tschwen] Date d'envoi : jeudi 19 septembre 1996 14:29 A : MHEG-5 IS Cc : MHEG Verification Group Objet : FWD>Remaining issues
Dear all, I am somewhat surprised by the lack of opinions on most points, (especially on the BER vs DER issue). Anyway, here are the results: 1a. 2: Yes. 3a. 4.1b, 4.2a, 4.3a, 4.4b. 5.1: Yes. 5.2: an explanation will be added, but no major problem there. 6a. ((Note; TN and ASN.1 must be changed!)) 7b. ((DER is now the official encoding rule for ASN.1)) 8: Yes.
(Did anyone score a perfect score? :-> )
For the clear meaning of these number refer to my previous mail reproduced below. Sincerely, Tom --------------------------------------MESSAGE 4 Date: 9/18/96 6:28 PM From: Tom Schwengler Hi folks, I have finally done most of the changes and comments that are more or less unanimously agreed... However, the following point either remain opened in my mind, or I just want to pound one more time that it is the solution we are adopting. I'd appreciate everyone's opinion on each subject.
(...)
3. Call/Fork parameters. No consensus on that point. 3a. Parameters is a list of GenericBoolean | GenericInteger | ... 3b. Parameters need be separated in In and Out parameters, InParameters are GenericBoolean | etc., OutParameters are ObjectReference. At this point, I would like to suggest 3a for the following reasons: technically it allows reference for IN/OUT parameters as well as direct IN values, practically it is in all preIS documents (it was put there after discussions in Rennes and Tampere to harmonize with MHEG-6) and I don't wish to step back so late in the editing process. So please keep this in mind when you send your opinion.
(...)