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

Re: DOM based API

From: Mark Baker <distobj@acm.org>
Date: Mon, 9 Jun 2008 10:20:41 -0400
Message-ID: <e9dffd640806090720r21cdba54q32102cafb5779901@mail.gmail.com>
To: "Maciej Stachowiak" <mjs@apple.com>
Cc: public-geolocation@w3.org

On Mon, Jun 9, 2008 at 12:49 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> Our goal is to invent an API, not to invent a markup language.

Says who?

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

"seem"?  You're going to have to better than that to dissuade me, Maciej.

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

Agreed.  Perhaps GeoLocationML will require DOM extensions, I don't
know, though I doubt it based on what I know of the space.

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

The Web is far more than just the data you pull off an HTTP
connection.  We have a file: URI scheme for a reason 8-)

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

Let's try and avoid the issue of how applicable the DOM is in the
general case, and just talk about Geo location.  Though I believe the
DOM surprisingly general, I don't need to convince anybody of that
here and now.

I am quite confident that if we defined a markup language that could
express a user's current location (or reuse the geo microformat,
doesn't matter to me), its use over the network would thrive, whether
used via an XHR POST to a group messaging service, or an XHR PUT to a
"Where are you" Wiki, or perhaps even via a FORM POST to a service
that prompts you from your current location.

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


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

I hadn't brought up queries, I just presented what I felt was a
valuable use of DOM event bubbling.  By not answering my question, are
you saying that wouldn't be useful to you or your users?

But since you bring up queries, and if you're suggesting the DOM isn't
optimal for them, I'm sympathetic to that position.  I suppose some
use cases would be in order.

Received on Monday, 9 June 2008 14:21:22 UTC

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