Lofton,
I think it sounds good, more in alignment with position as discussed
in yesterdays telecon. That is we want feedback but are not willing
change the interface at this time unless it's really serious defect. And
even then, we can always defer suggestions for change to 2.1.
Don.
> Per yesterday's telecon, final text to be sent. Any further comments?
> -Lofton.
> ---
> WebCGM 2.0 has (more or less) two sets of APIs: one that resembles a
> subset of DOM 2 Core; the other that resembles a subset of DOM 2
> Event.
> Why not use DOM 2 Core or DOM 3 Core? The main reason is that we
> thought an XML DOM API would create a lot of confusion to CGM (binary
> format) users. Also note that DOM 3 Core in its entirety is not needed
> by CGM users. That being said, because of the wide use of DOM Core, we
> tried to define a similar set of interfaces in an attempt to ease
> script writers the burden of learning something completely different.
> We also considered the fact that DOM Core has proven to be a reliable
> set of APIs and thus, seemed like a good basis for WebCGM 2.0.
> With regards to the Event APIs. Again, we defined our interface by
> borrowing heavily from DOM Events. The entire DOM 2 or 3 Event
> specification are simply too much for the WebCGM use cases. As you
> will notice from reading the WebCGMEvent interface, we do have a very
> small subset in mind.
> Therefore, for these two sets of APIs... we are looking for feedback
> such as: wrong parameter/return types; flaws in the wording with
> respect to a particular node type; critical omissions; wording that you
> believe is unclear to a script writer, etc...
> Summary. Several preliminary implementations validate that these
> interfaces are functional. We hope the Web API group can help us
> identify defects or mistakes we could have missed.
> ---