Re: DOM based API

On Sun, Jun 8, 2008 at 10:38 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> I've not seen Web developers having a problem with the fact that many APIs
> in the browser are not DOM trees

That's completely beside the point.  If you invented a new Javascript
interface for HTML5 documents, different than the HTML DOM, there
would of course be a learning curve?  So why invent a new DOM for
GeoLocationML documents?  At least that's how I look at this problem,
and I don't think that perspective is any less valid than yours.

Let me ask another question, to help me better understand your
position.  What if GeoLocationML was already a widely supported
document format?  Would you be any less in favour of defining a
specific API?

>. The main conceptual reuse I see as
> valuable is the concept of DOM events, whether tied to DOM nodes or not. The
> fact that occurrences related to non-Document-tree objects such as Window
> and XMLHttpRequest are represented as Events on an EventTarget allows for
> useful code reuse, since there are many libraries building on top of
> DOM-style event handling.

Agreed, events are a huge value-add.

But without the DOM, DOM events are just events (duh! 8-).  I see
considerable value in the event flow model.  For example, one might
consider defining a document to capture the state of the messaging
system of the client device, with a hierarchy something like;

Messaging
  Incoming
    SMS
    Email-folder1
    Email-folder2
    IM-acct1
    IM-acct2
  Outgoing
    SMS

etc..

I can see many scenarios where a script might be interested in
registering for, say, any incoming message, which it can do so using
DOM events, so long as the event fired from Incoming/SMS bubbles up to
Incoming so it can be captured there.  Is that not appealing?  Would
there be a simpler way to do this without the baggage of the full DOM
event model?

Mark.

Received on Monday, 9 June 2008 04:35:42 UTC