We apprechiate your mail-backlog!
> 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.
Message 5 says on the issue 3a (which was selected somehow):
> 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.
But this is not an answer to the question, since it only deals with the
formal parameter lists.
Message 2 helps more:
> 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.
That's it. I would not object here.
But as I said before, such a thing needs a private description anyway.
If the object is a variable, it can be changed.
Additionally I would say: If the program takes a objectreference as
input, and deferences the reference, and it happens, that the
defererenced object is a variable as well, it's value can be changed by
the program.
> 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.
Since a number of well known official experts are together in Tokyo next
week, we may expect a SC29 opinion later. MUG should document this (and
Tom's TechFAQ as well).
So long,
- 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