I agree with Xavier and Klaus to be conservative in the aspects of changes
or, much more sensitive subject, additions to the standard.
IMHO, the ResidentPrograms defined by Davic are not standardized in the sense
of ISO, but are depended on the application domain definition. But neverless,
they are very good solution to the problem.
On Thu, 22 Jan 1998, Emmanuel BEUQUE wrote:
> À (At) 10:32 +0100 22/01/98, Guillaume AUDEON écrivait (wrote) :
> >This looks simple but unfortunately cannot work. Because
> >GetLastAnchorFired returns its result in an OctetStringVariable and
> >SetData takes the new content reference from a ContentRefVariable. And I
> >have not been able to find a workaround in MHEG-5.
>
> Guillaume certainly pointed out an MHEG inconsistancy here. IMHO,
> GetLastAnchorFired would have better used a ContentRef variable rather than
> an OctetString one.
Hmm, for the particular problem Guillaume pointed out where he wants to
develope a generic browser this might be a problem. But, if you have the
possibility to parse the HTML beforehand and generate links which trigger
on the AnchorFired event with the specific event data of the URL, this
is not needed. I think, that was the original idea behind this. To assume
that the anchor data is an address limits the usage of this mechanism.
> >In addition, I found a solution provided by the DAVIC specifications:
> > the use of a ResidentProgram, named "CastToContentRef".
> >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?
>
> It's true that this kind of problem could be easily solved if there were
> more variable type conversions allowed. Currently, there is only Integer
> <-> OctetString conversions in MHEG-5 through the SetVariable action. It
> would be interesting to have more such as OctetString <-> ContentRef but
> why not others like Integer -> Boolean or Integer <-> ObjectRef and so on
> for any conversion that could be useful.
I see no problems with OctetString<->ContentRef because internaly the
ContentReference is only an OctetString, too (please help me, I can't
remember the heavy discussions about the conversions anymore...:(.
With Integer<->Boolean it is a problem: what is the Integer representation
of the Boolean value?
What about Integer<->ObjectRef (or OctetString<->ObjectRef)? This is even
more a problem because you either loose something in the conversion process
or make assumptions about the format of the ObjectReference.
Best regards,
Andreas
-- o _ Andreas Kraft (\_|_) GMD FOKUS, kraft@fokus.gmd.de, +49 30 3463-7232 T> ] [ The sky is the limit