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

Re: DOM based API

From: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 8 Jun 2008 21:49:14 -0700
Cc: public-geolocation@w3.org
Message-Id: <45DFC978-CFA3-4E6A-8BFE-3D16C0B5C3E8@apple.com>
To: Mark Baker <distobj@acm.org>


On Jun 8, 2008, at 9:35 PM, Mark Baker 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.

Our goal is to invent an API, not to invent a markup language. In  
particular, we want to provide an API to get the user's physical  
location. A markup language is one possible way to represent location,  
but it does not seem like an especially good one. So why assume there  
must be a GeoLocationML involved? After all, to query installed  
plugins, you don't have to process a PluginDatabaseML DOM. To open a  
new window or change size or location of an existing one you do not  
manipulate the WindowML DOM.

I would also add that the popular standard markup languages such as  
HTML and SVG have many features layered on top of the DOM core to make  
them easier to work with.

> 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?

This isn't entirely hypothetical, since there is already the "geo"  
Microformat. But we're not getting documents off the Web here, we are  
binding to native APIs on the client device. Markup languages are  
great for distributed data interchange, but introducing one just to  
get data from a native client device API to a Web application running  
on the device does not add much that is useful. And the format you  
would use for data interchange is not necessarily appropriate for  
notification or monitoring either. For instance, I do not see how the  
"geo" Microformat would make a sound basis for queries about the  
current location or requests for reverse geo mapping.

>
>
>> . 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'm not sure what you are getting at. DOM Events dispatched to the  
XMLHttpRequest object are certainly DOM Events, even though an XHR  
instance is not part of any document tree. Likewise for the Window  
object.

> 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?

It's not especially appealing to me - the DOM is not rich enough for  
the kinds of queries you want to do against a message data store. If  
any generic framework were appropriate here it would be a SQL database  
or an RDF datastore. But this is pretty off-topic.

Regards,
Maciej
Received on Monday, 9 June 2008 04:50:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:39 GMT