Re: DAP rechartering

Hi Claes, Dzung,

On Mon, Feb 28, 2011 at 2:45 PM, Nilsson, Claes1 <
Claes1.Nilsson@sonyericsson.com> wrote:

> Hi Dzung,
>
>
>
> I am also interested in addressing sensors. We have had discussions at the
> DAP list on this matter and there are worries about scope creep. Richard
> wants us to take small steps and has proposed an events model (similar to
> DeviceOrientation event draft
> http://dev.w3.org/geo/api/spec-source-orientation.html ) for well-known
> sensors (
> http://lists.w3.org/Archives/Public/public-device-apis/2011Feb/0050.html).
>  I agree that this is a good approach for common use cases where access to
> sensors that are well-known today is required.
>

Yes. There would be a lot of value to exposing well-known sensors without
trying to pack in extensibility and discovery in the first instance.


>
>
> However, this does not solve access to general sensors, actuators,
> accessories etc and the web is behind native application environments that
> provide Bluetooth, USB and RFID/NFC APIs.
>

These things wouldn't have to be excluded from the charter - just that
extensibility and discovery are nice-but-complex features when we could more
easily target the low-hanging fruit of exposing discrete,
simple-but-high-value sensors in the first instance (as noted above, in a
similar way to the Device Orientation Events API and reusing a lot of the
work from the System Info API initiative).

We should separate these things in the charter.

There'd be no reason why we couldn't consider producing things like (for
example) a Bluetooth/USB/RFID Device Connection API and an
OBEX-JavaScript-Interchange API under the new charter. Such things could be
filed under 'Other deliverables' or in plain English: 'a few deliverables we
would explore and *might* produce, pending workable input proposals'. That
would remain separate to the discrete sensors stuff that would be filed
under 'Deliverables' in the charter or: 'things we *will* produce since we
have a good idea of how to do them today'. Whether we need to settle on the
discrete sensors to expose in the charter is an open question from me. I'd
like to pin-point the exact sensors we would plan to expose very early on.

Proposals would be interesting in that area of discoverability and
extensibility. It's just really really hard compared with exposing some
simple, discrete sensors to the web that would already provide a lot of
value-add.


>
> Dzung, I am curious on your view. What do you propose? Could we provide
> something flexible but still reasonable simple for developers? Furthermore,
> Bryan, Paddy, you have mentioned that Bondi sensor/Bluetooth API. Any
> experiences on these APIs you can share?
>
>
>
> For the charter Richards proposes that we just state that we are providing
> an events model for well-known sensors. Any additional
> extensibility/discoverability/low-level API proposals could be considered
> for publication under the charter term. Such an approach would sounds nice
> and flexible but would this approach work from the W3C Patent policy point
> of view?
>

As far as I know, royalty-free on W3C specs is only established once it
completes all the patent exclusion periods. That's not really something that
can be known before the group starts to produce something. Anyone care to
elaborate on that?


>
>
> Regards
>
>   Claes
>

Cheers,

Rich


>
>
>
>
>
>
> *From:* public-device-apis-request@w3.org [mailto:
> public-device-apis-request@w3.org] *On Behalf Of *Tran, Dzung D
> *Sent:* den 23 februari 2011 17:53
> *To:* SULLIVAN, BRYAN L (ATTSI); public-device-apis@w3.org
> *Subject:* RE: DAP rechartering
>
>
>
> +1 agreed.
>
>
>
> I was planning to send out a message about rework of System Info, but I
> think this is well said below. Also when DAP started, we wanted to work on a
> sensor APIs, which were put on hold till v2 with agreement from the group.
> We should revisit these sensor API.
>
>
>
> Thanks
> Dzung Tran, Intel
>
>
>
> *From:* public-device-apis-request@w3.org [mailto:
> public-device-apis-request@w3.org] *On Behalf Of *SULLIVAN, BRYAN L
> (ATTSI)
> *Sent:* Wednesday, February 23, 2011 8:31 AM
> *To:* public-device-apis@w3.org
> *Subject:* DAP rechartering
>
>
>
> I commented on the call that if the group decides to change the approach to
> discrete system information property access and sensors, away from the
> current approach of the Sysinfo spec (an common interface through which
> various properties can be accessed), I suggest rather than try to evolve the
> current spec in that direction, DAP start new with new spec(s) for the
> discrete purposes. This would allow as Richard proposed, that the
> implementers be able to focus on discrete properties/sensors as they become
> needed and implementable. It will also help avoid the potential
> fragmentation with other API designs that do exist in the market, which are
> more aligned with the intent of the Sysinfo design as it stands today, and
> are supported by a number of implementations already.
>
>
>
> This is in general an approach I think DAP should take with the APIs in its
> charter. Where it has not completed work on APIs that were in fairly
> complete form when originally submitted as input to DAP two years ago, that
> indicates to me a difference in vision and API design approach which may not
> easily be resolved at this point. DAP should not continue to struggle with
> what may be a working approach with limited success potential, i.e. trying
> to merge to significantly different visions for APIs into a single set of
> specs. If W3C was able to complete these specs, in the end they probably
> would just confuse the market and cause fragmentation impacting vendors
> which have to implement two APIs for the same purpose (with different widely
> models for API design, user interaction necessity, and security/privacy).
>
>
>
> Thus I think DAP should drop those APIs it has not finished and focus on
> new work that does not conflict with the other work in these areas which has
> continued in the market in the last two years, and which is now widely
> supported, and likely to be brought to W3C for standardization in the near
> future. This sequence should be familiar to W3C members: market initiative
> and W3C response (group/work initiation), with implementations continuing to
> be developed, and eventually driving W3C to refocus on supporting the actual
> implementations in the market. DAP has the opportunity in this rechartering
> phase to recognize and respond to that need for realignment in the work that
> W3C is doing in this area.
>
>
>
> We still firmly support the API scope in the original DAP charter, but I
> question if it’s effective to keep struggling to address them under DAP’s
> new charter. Thus I would rather see DAP focus on a unique API scope, to
> avoid market fragmentation.
>
>
>
> Thanks,
>
> Bryan Sullivan | AT&T
>
>
>