Re[5]: [cgmo-webcgm] Ecmascript binding question

[Benoit Bezaire <benoit@itedo.com>]

Hi Lofton,

See comments inline...

Tuesday, August 17, 2004, 5:30:08 PM, Lofton wrote:

LH> At 02:55 PM 8/13/2004 -0400, Benoit Bezaire wrote:
LH> Hi Lofton,

LH> It's a question I've asked myself as well.  I think the answer hasto
LH> do with data types and inheritance.  For example, what is the
LH> equivalent to DOMString or boolean?  That could be different basedon
LH> the language.  The C language for example doesn't have either ofthose
LH> data types, so the mapping has to be clear.  But for Ecmascriptthe
LH> mapping is clear (Boolean and String exist).

LH> So as I understand you and Dieter's position, we will share a
LH> common IDL definition of WDOM, and most or all stuff in the IDL
LH> definition has a fairly obvious mapping to Ecmascript. 
I would add that we are willing to publish an ecmascript binding when
going into Candidate Recommendation, although other individuals are
more than welcome to do so.

LH> Therefore, amongst the expected five CGMO implementors,
LH> instead of writing down and sharing a common Ecmascript binding
LH> once and for all time,
I don't even know what 'sharing a common Ecmascript binding' implies?
I can't speak for other implementations but expanding an activeX
control is quite implementation dependent.

LH>  we will rely on the assumption that reasonable techies at the 5
LH> companies will all come up with exactly the same Ecmascript
LH> bindings of the IDL, in every detail that would matter at the
LH> application programming interface.
I think that the IDL doesn't help very much, the 'techies' can do the
same number of mistakes with the Ecmascript binding.  Providing the
Ecmascript binding (in my opinion) doesn't reduce implementation time
at all.

LH> So my questions now are...

LH> 1.) is that a reasonable assumption, programmers being
LH> programmers? (Hey ... nothing negative intended ... I are one too!)
We all make mistakes.  We'll end up with mistakes with the IDL and/or
with the ecmascript binding.

LH> 2.) what about application writers amongst WDOM users? 
LH> Rather than giving them a shared, common Ecmascript definition, are
LH> we going to tell them to either guess/derive it from the IDL
LH> themselves, or look at someparticular WDOM vendor's product
LH> documentation?
That's what I don't get... there's nothing to derive.  If the IDL
says:
void setStyleAttr(in DOMString style, in DOMString value);
There's little room for error.
The function name is 'setStyleAttr'.
The is no return value.
The first parameter is the style of type string.
The second parameter is the value again of type string.
The function doesn't throw any exceptions.

LH> 3.) what about cascaded profiles (e.g., AECMA, ATA)?  "It's
LH> a trivial exercise, left to the reader."?
What about cascaded profiles?  There are more important issues
regarding cascaded profiles than the ecmascript binding.

LH> I'm not completely comfortable yet with "yes" answers to all
LH> of those (i.e., we're not going to document a single common
LH> Ecmascript binding).  It runs against the grain of my past
LH> standards experience.
And I agree, but what I'm saying is that we don't need the ecmascript
binding at this time.  Only later for W3C process.

LH> Thoughts, anyone?
Spending time on a test suite is far more valuable in my opinion than
spending time on an ecmascript binding.  An ecmascript binding won't
prevent bugs from being introduced in implementations, but a test
suite can catch them though.

LH> One last comment...

LH> At 06:12 PM 8/13/2004 +0200, Dieter Weidenbrueck wrote:
LH> [2] says:
LH> "Note that this language binding is not normative. The IDLDefinitions are
LH> the normative parts of the SVG DOM."


LH> Yes, but people don't write IDL, of course.  They write
LH> JavaScriptor JS or Ecmascript (or Java or C++ or ...).
Vendors write IDL. Users write JS.  That's why I say that vendors
don't need the ecmascript binding at this time.

LH>   And SVG
LH> *did* writedown their Ecmascript binding [2], even though they
LH> called itnon-normative.  I suspect, actually, that there was some
LH> confusion about "normative" label.  Perhaps "normative" was thought
LH> to mean, "you must implement this Ecmascript binding" (regardless
LH> of your actual language of interest).  As opposed to, "if you
LH> implement SVG DOM in Ecmascript, you must do it like this to have a
LH> conforming implementation".

LH> That's just a guess.  Because I can't imagine why anyone
LH> would want,in a supposedly interoperable standard, to allow two
LH> distinct differing bindings in the same language to both be
LH> considered" conforming".
Again, I think that publishing the ecmascript binding is a good thing.
But that can be done later, when we are done.

Regards,
Benoit.

LH> Regards,
LH> -Lofton.

LH> P.S.  [1] gives some hint about significant issues (e.g.
LH> multipleinheritance) that bindings must resolve in SVG DOM (which
LH> we won't facein WDOM, I guess) ...

LH> [["The SVG IDL defines the model for the SVG DOM. Note that
LH> theSVG IDL is defined such that some interfaces have more than one
LH> baseclass. The different standard language bindings for the SVG
LH> DOM areresponsible for defining how to map all aspects of the SVG
LH> DOM into thegiven language, including how the language should
LH> implement interfaceswith more than one base class."



LH> ]]

>>>[1]http://www.w3.org/TR/SVG11/idl.html
>>>[2]http://www.w3.org/TR/SVG11/escript.html



-- 
 Benoit   mailto:benoit@itedo.com