RE: SetData & ContentRef

Xavier MARIE (Xavier.Marie@cril-ing.fr)
Thu, 22 Jan 1998 14:10:54 +-100

Folks,

Klaus and Guillaume wrote:
>> Would not it be simplier to extend the SetVariable action to take into
>> account OctetString <-> ContentRef conversions?
>> Should not this be addressed by the MHEG-5 Maintainance Task Force?

>However, my first word on that would be that this is a serious change in
>MHEG and therefore there should be very good reasons to do so, and there
>should be broad acceptance.

>I would rate that serious, since potential existing engines have already
>implemented the DAVIC ResProgs (or others) to do that. Therefor, such change
>would introduce the risk of inportability.

>Any other opinions on that important issue, please?

I agree with Klaus - I would put it more strongly.
The standardised resident programs provide a solution.
It is not fully satisfactory, nor perfect - as with many other features of MHEG-5.
But it is TOO LATE to complain about this.
Changing the standard now in such respect would open
a potential for divergence between implementations,
thus non-interoperability, whose consequences to the market success
of MHEG would be disproportionate to the cause.

As far as the maintenance task force is concerned, maybe it should
develop (and agree on) clear rules for eligibility of proposed changes.
This might greatly help subsequent procedure, and avoid any emotional
or subjective considerations like comparing the value of requirements.
(There is no point in discussing each item individually,
when some requests could be filtered away from the start).
I would support a rule stating that any proposal for technical change
shall be motivated by one or several features that are required
by the application domains of MHEG-5, and for which
neither MHEG-5 nor its associated specifications provide any support.
(including application domain things like resident programs).

In other words, technical changes can't be entered just
to give more comfort to the programmer.
This does not imply that changes needed for functional reasons
have to be accepted. This just means they can pass the filter,
unless or until someone finds a workaround for these.

Best regards
Xavier