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

Re: DOM based API

From: Mark Baker <distobj@acm.org>
Date: Mon, 7 Jul 2008 00:14:03 -0400
Message-ID: <e9dffd640807062114k73f3adf0ucd50e8fe2982f562@mail.gmail.com>
To: "Dave Raggett" <dsr@w3.org>
Cc: public-geolocation@w3.org

Hi Dave,

On Fri, Jul 4, 2008 at 3:02 PM, Dave Raggett <dsr@w3.org> wrote:
> Hi Mark,
> If you are looking for a DOM based API in the sense of one based upon XML
> nodes, then the DCCI is an existing framework. We had hoped to define an API
> for location about a year ago, and Ryan Sarver joined as an invited expert
> to work on that, but he was too busy with Skyhook Wireless to devote enough
> time to progress the standards work in the UWA working group.

Gee, I thought I had a monopoly on that idea. 8-)  Nicely done, that's
just what I was talking about (at least with a quick scan of Section 3
of the DCCI spec).

> Location was always one of the use cases for DCCI right from the very start,
> several years back when the work was started in the Multimodal Interaction
> working group. We anticipated there being subproperties that would control
> the conditions under which location updates occurred and the data format it
> was presented in.

Absolutely.  It's surprisingly flexible.  It's unfortunate that a W3C
*Webapps* WG doesn't appear to fully appreciate the utility of one of
their own foundational tools.

> Location is part of the current working draft for the
> delivery context ontology, and we are likely to model some of the common
> parameters for location updates in future drafts, tracking the work of the
> Geolocation WG. The general aim is to allow a straightforward mapping from
> the delivery context ontology onto a DOM based API.

It would be unfortunate if a mapping had to be defined IMO, rather
than simply reusing the same access mechanism.  How different are the
use cases for your location access effort, vs. this one?

> Browser vendors haven't been enthusiastic about a general framework for
> accessing user preferences, device capabilities and environmental
> conditions, preferring instead to take a piece meal approach that caters for
> each device capability on an individual basis. That is unlikely to scale
> well when it comes to describing a much wider range of devices as is need to
> realise the web of things. Future web applications may not involve a browser
> at all.

Well, there's always a browser, in some shape or another 8-)

The scaling problem isn't the typical one one thinks of when thinking
"Web" and "scale" though, it's more an issue for developers.  IMO, the
Java platform slowly killed itself by burdening developers with
learning a brand new API for every new requirement that came its way.
I really hope that doesn't happen to the client-side of the Web, but
it looks like that's the path it's on right now with Gears and HTML5.
What's distressing to me is, as mentioned, that a solution to keep it
in check (I don't claim the DOM is suitable for all client-side APIs)
is right under our noses.


Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Coactus; Web-inspired integration strategies http://www.coactus.com
Received on Monday, 7 July 2008 04:14:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:51 UTC