W3C home > Mailing lists > Public > public-webcgm-wg@w3.org > June 2006

re[3]: what kind of feedback from Web API?

From: Don Larson <dlarson@cgmlarson.com>
Date: Wed, 14 Jun 2006 17:25:28 -0500
To: <public-webcgm-wg@w3.org>
Message-ID: <E1FqdmJ-0006bP-Hi@maggie.w3.org>

WG,

>I have spent some time studying the webapi and don't really see any
>issues to webcgm dom.
>
>
>After reading Benoit's initial position, I think his argument that we need
>a lightweight event model for webcgm is reasonable. Also I think that the
>amount of events that we need to deal with in a graphics DOM (typically
>a graphics 100 to 200 hotspots) further warrants our own event definitions.
>
>I think it's good however to get webapi's feedback on our interface
>definitions, like do they make sense to a javascipt writer that
>is already familiar with XML DOM API.
>

Don Larson.



  > Tuesday, June 13, 2006, 10:22:50 AM, Lofton Henderson wrote:

  > > In haste this morning (more later)...
  > Ok. In the mean time...

  > <snip>
  > >>--
  > >>   Here is an attempt to clarify our request. 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 entirely 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; not to undermine 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.
  > >>
  > >>   Therefore, with regards to the DOM Core like APIs... we are looking
  > >>   for feedback such as: wrong parameter/return types; flaws in the
  > >>   wording with respect to a particular node type; wording that you
  > >>   believe is unclear to a script writer, etc... Additionally, your
  > >>   experience can help us identify areas where our interfaces could be
  > >>   improved for usability.
  > >>
  > >>   With regards to the Event APIs. We have ourselves, been wondering
  > >>   what would be the best course of action: defining our own interface
  > >>   or using DOM Events.

  > > (Trivial comment: the wording makes it sound like design of our
  > > Event Model is a future endeavor. In fact, it is done and in Last
  > > Call and we're wondering if we can improve alignment.with the Web
  > > API framework. We can deal with this minor observation when we
  > > compose a final answer.)
  > Ok.

  > >>We don't however, want to reference the entire
  > >>   DOM 2 or 3 Event specification; that is simply too much for the
  > >>   WebCGM use cases. We could use advice on how best to reference a
  > >>   subset DOM Events. As you will notice from reading the WebCGMEvent
  > >>   interface, you do have a very small subset in mind.

  > > As you note above for DOM Core, we took guidance from it. Is that
  > > not the case also for our events and DOM3E? From my weekend reading
  > > of DOM3E, it seems so. (This question is just clarification for
  > > myself, not necessarily a suggestion for change at this point.)
  > Yes, we took guidance from DOM3Ev.

  > >>   We do understand that some of the comments could suggest
  > >>   substantial changes to the specification.

  > > I don't know what this means. How would you intend the recipients to
  > > interpret it?
  > That we are opened to the idea of referencing a subset of DOM3Ev
  > rather than re-inventing our own.

  > > Clearly, we want to avoid massive substantive changes at this stage,
  > > and Bjoern's comment (see [1]) acknowledges that would is
  > > problematic at last call.
  > Agreed, we want to avoid substantive changes.
  > However, it is my opinion, that if we could reference a subset of
  > DOM3Ev (i.e., the subset we duplicated), few changes are needed on
  > implementations and test suite.

  > Please see how the SVG Tiny 1.2 specification created a subset of
  > DOM3Ev (member-only):
  > http://www.w3.org/Graphics/SVG/Group/repository/spec/mobile/1.2/1.2NG/publis
  > h/svgudom.html#events

  > How much work would it be to do something equivalent?

  > > I'd be inclined to summarize with something more like this, "In
  > > summary, we hope that the experts of Web APIs can help us to improve
  > > the alignment of WebCGM 2.0 with Web API technologies and
  > > specifications, while avoiding major substantive changes, which as
  > > noted are usually best avoided at Last Call."
  > This to me, seems like you are not open to the idea of referencing a
  > subset of DOM3Ev. Am I correct in assuming so?

  > The group needs a position on this.

  > Another thing to consider thought is that DOM3Ev is still in WD
  > status. I'd like to reference DOM3Ev, but I don't want us to be stuck
  > in CR because they are still in WD? However, we are likely to subset
  > old DOM2Ev APIs, those are unlikely to change.

  > -- 
  > Regards,
  >  Benoit   mailto:benoit@itedo.com


  > > All for now,
  > > -Lofton.


  > >>
  > >>Monday, June 12, 2006, 4:14:31 PM, Lofton Henderson wrote:
  > >>
  > >> > WebCGM WG,
  > >>
  > >> > [1]
  > >> > http://lists.w3.org/Archives/Member/member-webapi/2006Jun/0014.html
  > >> > (member-only)
  > >>
  > >> > We should have a discussion about what kind of feedback we expect
  >  and/or
  > >> > would like from Web API WG, who is listed in our Charter [2] as one of
  >  the
  > >> > groups with whom we will coordinate.
  > >>
  > >> > Note that this coordination item was added to our Charter during AC
  >  Review
  > >> > phase, in reaction to a comment about the draft Charter received during
  >  AC
  > >> > Review.
  > >>
  > >> > Because of anticipated travel of a few WG members starting next week,
  >  we
  > >> > must take care of it this week.
  > >>
  > >> > CAVEAT (and mini-lesson) about confidentiality!  You will note that Web
  >  API
  > >> > is not a public group, whereas WebCGM is a public group.  Therefore, we
  > >> > must all be careful that we do NOT copy or forward email messages that
  >  have
  > >> > been sent to member lists but public lists.  Thus I have pointed to the
  > >> > email message [1], which is in a member-only archive, rather than
  > >> > forwarding it (which would put it in our public archive).  This might
  >  seem
  > >> > a little odd at first, but it just takes a little forethought (as I
  >  found
  > >> > out in the public QAWG -- learned the hard way by violating it a few 
  > >> times!)
  > >>
  > >> > Regards,
  > >> > -Lofton.
  > >>
  > >> > [2] http://www.w3.org/2006/03/webcgm-charter.html
Received on Thursday, 15 June 2006 01:57:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:19:08 GMT