OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Re[2]: [cgmo-webcgm] Ecmascript binding question


Hi Kevin,

>If there is not a standard ecmascript binding defined, then I will have to
>create two versions of my ecmascript, one for each WebCGM plug-in with its
>own defined ecmascript binding. This is not interoperable at all.
Why not? What would be the difference between the viewers, if they
implement their interfaces according to the IDL in the WDOM spec?

>>>   IDL snippet:
>>>   interface Attr : Node {
>>>     readonly attribute DOMString        name;
>>>     readonly attribute boolean          specified;
>>>              attribute DOMString        value;
>>>                                         // raises(DOMException) on
>setting
>>>
>>>     // Introduced in DOM Level 2:
>>>     readonly attribute Element          ownerElement;
>>>   };

It is absolutely clear how this should be implemented, or don't you think?
Where could be differences that matter in a script residing on an HTML page?

Regards,
Dieter

>-----Original Message-----
>From: Kevin O'Kane [mailto:kevoka@AUTO-TROL.com]
>Sent: Thursday, August 12, 2004 7:40 PM
>To: 'Benoit Bezaire'; Ulrich Laesche
>Cc: CGM Open WebCGM TC
>Subject: RE: Re[2]: [cgmo-webcgm] Ecmascript binding question
>
>
>All,
>   I will take a stab at explaining this problem. The reason an ecmascript
>binding must be defined is due to an inherent interface that will exist
>between the plug-in and the other presentation aspects of the application.
>
>Lets say I am a customer who is writing a presentation application
>that will
>be distrusted to many end users. My presentation application will utilize
>the WEBCGM DOM, and will be written in ecmascript. However, not all of my
>end users will be using the same WebCGM plug-in, as some will be using
>Product A and some will be using Product B.
>
>If there is not a standard ecmascript binding defined, then I will have to
>create two versions of my ecmascript, one for each WebCGM plug-in with its
>own defined ecmascript binding. This is not interoperable at all.
>
>Kevin
>
>-----Original Message-----
>From: Benoit Bezaire [mailto:benoit@itedo.com]
>Sent: Thursday, August 12, 2004 9:58 AM
>To: Ulrich Laesche
>Cc: CGM Open WebCGM TC
>Subject: Re[2]: [cgmo-webcgm] Ecmascript binding question
>
>
>Hi Ulrich,
>
>I'm not 100% sure I understand the question, but here is an attempt to
>answer.
>
>Applications can be exchanged if they use WebCGM standard API calls.
>They will be exchangeable between viewers that implement the WebCGM
>DOM API.
>
>If the application uses vendor proprietary APIs, it will not run in
>any other viewer.  All vendors *must* implement the API as per defined
>in the spec.  If a viewer implementation diverges from the spec(ie, changes
>function name, return type, parameter type), it will not be standard
>compliant.
>
>--
> Benoit   mailto:benoit@itedo.com
>
>
>Thursday, August 12, 2004, 11:07:18 AM, Ulrich wrote:
>
>UL> Hi Ben,
>
>UL> I didn't particularly ask for an Ecmascript binding.  My question was
>how
>UL> applications written with bindings from two or more different vendors
>could
>UL> be exchanged.  For example, will it be possible to use one vendors API
>and
>UL> to use another vendors viewer (in case the viewer vendor has the spec
>UL> implemented, of course)?
>
>UL> Thanks and regards
>UL> Ulrich
>
>
>UL> ----- Original Message -----
>UL> From: Benoit Bezaire <benoit@itedo.com>
>UL> To: CGM Open WebCGM TC <cgmo-webcgm@lists.oasis-open.org>
>UL> Sent: Thursday, August 12, 2004 4:05 PM
>UL> Subject: [cgmo-webcgm] Ecmascript binding question
>
>
>>> Hi all,
>>>
>>>   We have a question for CGM vendors regarding the Ecmascript binding.
>>>   During yesterday's call, all the vendors expressed the need for the
>>>   Ecmascript binding in order to start implementation.  Could it be
>>>   explained to us (Itedo developers) why that is so?
>>>
>>>   Our opinion is that the IDL snippet found in the spec provide all
>>>   the information needed for implementation.  If you believe that not
>>>   to be true, could someone please explain.
>>>
>>>   To us, an Ecmascript binding is the same as the IDL but using
>>>   different words.  Example (the DOM Level 2 Attr interface):
>>>
>>>   IDL snippet:
>>>   interface Attr : Node {
>>>     readonly attribute DOMString        name;
>>>     readonly attribute boolean          specified;
>>>              attribute DOMString        value;
>>>                                         // raises(DOMException) on
>setting
>>>
>>>     // Introduced in DOM Level 2:
>>>     readonly attribute Element          ownerElement;
>>>   };
>>>
>>>   Ecmascript binding snippet:
>>>   Object Attr
>>>   Attr has the all the properties and methods of the Node object as
>>>   well as the properties and methods defined below.
>>>   The Attr object has the following properties:
>>>   name
>>>       This read-only property is of type String.
>>>   specified
>>>       This read-only property is of type Boolean.
>>>   value
>>>       This property is of type String and can raise a
>DOMException object
>UL> on setting.
>>>   ownerElement
>>>       This read-only property is a Element object.
>>>
>>>
>>>   Could we be explained why this helps?
>>>
>>>   Regards,
>>>
>>> --
>>>  Benoit                 mailto:benoit@itedo.com
>
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]