W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2008

Re: DOM based API

From: Chris Prince <cprince@google.com>
Date: Sun, 8 Jun 2008 21:39:32 -0700
Message-ID: <cd580da00806082139t4d7404e9vbfe65536ed87f7c0@mail.gmail.com>
To: "Mark Baker" <distobj@acm.org>
Cc: "Maciej Stachowiak" <mjs@apple.com>, public-geolocation@w3.org

I'm with Maciej.  For geolocation, the arguments against using a DOM
tree seem stronger than the arguments for using one.  A DOM tree feels
like an unnatural fit.

On Sun, Jun 8, 2008 at 9:35 PM, Mark Baker <distobj@acm.org> wrote:
> 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:40:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:49 UTC