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

[Lofton Henderson <lofton@rockynet.com>]

At 02:55 PM 8/13/2004 -0400, Benoit Bezaire wrote:
> Hi Lofton,
>
> It's a question I've asked myself as well.  I think the answer has
> to
> do with data types and inheritance.  For example, what is the
> equivalent to DOMString or boolean?  That could be different based
> on
> the language.  The C language for example doesn't have either of
> those
> data types, so the mapping has to be clear.  But for Ecmascript
> the
> mapping is clear (Boolean and String exist).

So as I understand you and Dieter's position, we will share a common IDL
definition of WDOM, and most or all stuff in the IDL definition has a
fairly obvious mapping to Ecmascript.  

Therefore, amongst the expected five CGMO implementors, instead of
writing down and sharing a common Ecmascript binding once and for all
time, we will rely on the assumption that reasonable techies at the 5
companies will all come up with exactly the same Ecmascript bindings of
the IDL, in every detail that would matter at the application programming
interface.

So my questions now are...

1.) is that a reasonable assumption, programmers being programmers? 
(Hey ... nothing negative intended ... I are one too!)

2.) what about application writers amongst WDOM users?  Rather than
giving them a shared, common Ecmascript definition, are we going to tell
them to either guess/derive it from the IDL themselves, or look at some
particular WDOM vendor's product documentation?

3.) what about cascaded profiles (e.g., AECMA, ATA)?  "It's a
trivial exercise, left to the reader."?

I'm not completely comfortable yet with "yes" answers to all of
those (i.e., we're not going to document a single common Ecmascript
binding).  It runs against the grain of my past standards
experience.

Thoughts, anyone?

One last comment...

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

Yes, but people don't write IDL, of course.  They write JavaScript
or JS or Ecmascript (or Java or C++ or ...).  And SVG *did* write
down their Ecmascript binding [2], even though they called it
non-normative.  I suspect, actually, that there was some confusion
about "normative" label.  Perhaps "normative"
was thought to mean, "you must implement this Ecmascript
binding" (regardless of your actual language of interest).  As
opposed to, "if you implement SVG DOM in Ecmascript, you must do it
like this to have a conforming implementation".

That's just a guess.  Because I can't imagine why anyone would want,
in a supposedly interoperable standard, to allow two distinct differing
bindings in the same language to both be considered
"conforming".

Regards,
-Lofton.

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

[[

"The SVG IDL defines the model for the SVG DOM. Note that the SVG IDL is defined such that some interfaces have more than one base class. The different standard language bindings for the SVG DOM are responsible for defining how to map all aspects of the SVG DOM into the given language, including how the language should implement interfaces with more than one base class."

]]

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