Re: Parameters of the Call elementary action

Emmanuel BEUQUE (ebeuque@pratique.fr)
Fri, 11 Apr 1997 14:02:24 +0200

À (At) 20:19 +0200 10/04/97, Klaus Hofrichter écrivait (wrote) :
>C. THEOT (CCETT) (Tel 99124410) wrote:
>>
>> Which of the two following solutions is the correct one, according to :
>> 1/ what is actually written in the standard,
>> 2/ what you remind from discussions in the past, for those who took part
>>to them.
>>
>> Q: What is the correct way to return a value back from a Program ?
>>
>> Solution 1:
>> In IS, parameters of the Call action are now both In and Out.
>> ...
>>
>> Solution 2:
>> In IS, parameters of the Call action are now only In.
>>...
>
>As far as I remember, we have had both solutions under discussion.
>I think we have voted for the first at the end, but I am not that sure.
>Since we have not (yet) implemented this, we at FOKUS did not discover
>the ambiguity of the actual text.

It is my understanding that both solution should be possible, depending on
the type of parameters and on how the Program deals with these parameters.

In the provision of use, the MHEG-5 standard well distinguish the two kinds
of parameters that, as I understand, could be passed to the program :

"Parameters passed by value" could be of any kind I guess, including the
objectReference type. That way, if you pass an object reference to a
variable object, then the Program should be able to make IN/OUT action on
it with the getVariable/setVariable action of the MHEG-5 API defined in
MHEG-6.

On the contrary, parameters passed by reference to a variable shall used
":IndirectRef" I think since it is said that "Parameters shall be set to a
list of values ...". That way, as I understand, you only pass the value
stored in the Variable but this variable cannot be modified by the program.
In fact, the program should only see its value without knowing where this
value come from in that case.

I hope everybody understand things like me since it seemed rather clear in
my mind that things should act like this.

>However: Why don't you (or DAM) just define something for the specific
>application profile?
>May be a bit naive, but since a MHEG5-program class/object always needs
>additional documentation about the parameter for a particular (definitly
>unportable) feature, I would recommend "just do it". Who is going to
>complain?

Me! I'm certainly going to complain if everybody try to implement their own
solution. MHEG is supposed to provide interoperability. I agree that it
lets a lot of choice to the application domain but the answer to
Christine's question is (and definitely shall be) in the MHEG-5 standard.
If it would not, it would become a real pain to create an authoring tool
for MHEG, because of too many configurable stuff. I don't want to make an
authoring tool for DAM, but for MHEG. And you should all agree that without
authoring tools, there no need to make MHEG engines. They would be useless,
wouldn't they ?

> Only thing is, that the engine developers might see an
>influence on their design. Depending on the design of the Program-Class
>Interface one of the solutions might be simpler.

I can't stand this way of developing where one choose the solution that is
easiest on their side and let the others deal with the difficulties they
didn't want.

>On the other hand, I think that the MHEG-6 people have a more definitve
>answer to the question, since they deal quite much with parameter
>passing.

Yes, and there, I think that MHEG-6 should clarify things and fix them for
everybody.

Regards,

__________________________________________________________________
Emmanuel BEUQUE Email: ebeuque@pratique.fr
mediaServ tel: +33 (0) 2 99 64 36 64
Multimedia consultant & developer fax: +33 (0) 2 99 64 36 65
__________________________________________________________________