ACCESS' input, was: RE: Proposal for new WG to specify "Concrete APIs"

Dear Art, Nick, All,

ACCESS would like to welcome and support the idea of the creation of the Device API WG in W3C.
ACCESS is willing to actively participate in this WG. We are interested in the chair and/or editor position and are able to devote the necessary time for these role(s) as stated in the proposed charter.
The proposed candidate for this/these role(s) would be me.

The NOKIA's proposal is a very good input to the proposed WG.
ACCESS supports also the idea of BONDI specifications being the second contribution for the proposed W3C WG. This contribution is already pre-agreed by all the BONDI members (a few tens of mobile operators and vendors) and this fact should facilitate the standardization process.

The "associated inputs" from BONDI as quoted below are close to trivial, I agree. BONDI contributors have developed tools to split the actual semantics of the specifications from their actual syntax; this is valid specifically for the BONDI Interfaces specification expressed in WebIDL with the associated HTML documentation. It shall be quite easy to transform this input to follow the W3C's standard specification layout.

Both BONDI WGs - Architecture&Security (A&S) and Interfaces (IF) - are now working hard to deliver the release 1.0 of the specifications.

Please allow a few more weeks for those specifications to be released, since there is the overwhelming amount of supportive comments from many BONDI contributors that both BONDI WGs want to accommodate in the initial, stable version of the specifications. The current plan in BONDI is to have those specifications ready by the end of May/2009 at the latest. I think it is better to input to W3C the most agreed and verified specifications at that slightly later time than to be in a hurry and provide unstable or clearly buggy inputs.

I think that in the period of waiting for the BONDI inputs and in order not to waste the precious time, the interested parties could work on the organizational side of the proposed Device API WG and its internal set-up, possible work-flows and dependencies.
With regard to this, please find attached a revised charter for the proposed WG.

ACCESS would like that the security policy model specified by BONDI A&S WG be revised within W3C in order to gain even more industry-wide support. It is practically irrelevant whether this would be done in the Device API WG or within any other WG as far as the consistency of the specifications and temporal relations are guaranteed. Since, however, both APIs and security policy remain in close technical relation it may be advisable to carry out the related standardization tasks in the single Device API WG.

Building upon the experiences from BONDI, I would like to suggest the following way of operation of the Device API WG:

1. The work on APIs in the Device API WG could be split into formal or informal sub-(working)-groups (SWGs) as follows:

a) API Design Patterns SWG would work on the general API rules that would govern the architectural aspects of all APIs defined in the WG, additionally to the general rule to define the APIs in WebIDL. I assume this specification could/should be released earlier than the others for practical reasons. The Appendix A proposed by NOKIA partially addresses the scope of this activity.
Example areas of the related work are:

i) API asynchronicity model

ii) Naming conventions

iii) Error and exceptions model

iv) API versioning model

v) Models for device capability, API and API features identification

b) For each API specification defined within Device API WG there would be a specification lead / editor(s).

It is assumed that the API Design Patterns could help to separate the semantic and syntactical aspects of each API, so that the actual specifications could be delivered in the timely manner.

2. The scope of the Device API WG should be extensible.

As an example please consider that BONDI IF WG defines now 14 different sets of APIs. There is partial overlapping between those APIs and the work pursued in W3C, specifically for the Location API and preferences from Widgets 1.0. There should be a clear plan to unify those APIs.

What's more and as you may also know, within BONDI the contributors have recently identified more than 50 new sets of APIs that could be standardized in the near future.
Thus together with the API versioning model (initial input from BONDI), W3C's Device API WG could identify the best ways and practices to facilitate the improvements, modifications and additions of the APIs and their deployment on the software platforms, specifically to ease the life of the developers using those APIs within various environments.

Having API versioning model seems to be semantically equivalent to the updates of the Working Drafts in W3C, but in my personal opinion, API versioning model is more transparent to the actual API user and shall be discoverable by the web application code.

I hope we will have further fruitful discussion about the charter and will reach the consensus soon.

Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Arthur Barstow
Sent: Tuesday, April 28, 2009 1:51 PM
To: ext Nick Allott
Cc: public-device-apis@w3.org
Subject: Re: Proposal for new WG to specify "Concrete APIs"

Hi Nick,

On Apr 27, 2009, at 8:51 AM, ext Nick Allott wrote:

> 2) Charter: this initial input looks good  - a few early comments:
>
> a) Do we have to be tighter on scope of APIs? The charter presumably
> helps form part of the practical sandbox for RF commitments. Given the
> issues with Geolocation, I would have anticipated that this may be an
> issue, upon which we need clarity. (To be clear I think here I would
> personally advocate wide rather than narrow scope, but important that
> this is raised.)

If your question is effectively "does the Charter need to explicitly
enumerate all of the APIs in scope for the WG?", then yes, I see this
as a mandatory requirement and I would expect some Consortium Members
to object to an open-ended Charter.

If OMTP and/or its Members want to add to the list we proposed, then
I think all we need at this stage is a short one-line description of
the API and an associated input (file) so we can all get a reasonable
understanding of the APIs scope.

Given the related work BONDI has already done, I would think that
creating these "associated inputs" would be trivial i.e. just cut and
paste the latest-and-greatest version of each API into a separate
ASCII file.


> b) Should policy description and APIs be in the same charter. There
> are
> arguments both sides, and as we discussed briefly in Boston, I am
> sympathetic to the Nokia position. It is critical however, that if
> they
> are, under the same charter that the security element be identified
> as a
> distinct deliverable, with potentially different timelines. I will
> raise
> this issue internally and try to get a formal OMTP consensus
> position on
> this issue (ie separate security charter vs APIs). We also have some
> ongoing conversations with W3C staff on this same issue that we
> hope to
> resolve shortly.

I think Thomas Roessler set the tone here regarding one or more WGs
by explicitly excluding device service APIs from what I'll call his
"Security Policy WG" proposal [1].

The most important thing is for the work to begin in an open and
transparent forum as soon as possible. I am mostly indifferent about
one versus two WGs and will tend to favor the solution that expedites
starting the work.


> 3) Contribution and editor resources. Similarly, we can offer the
> editor
> and strong
> support on the resourcing sides should this go forward. We will report
> back on the detail (names) soon.

Good to hear.

-Regards, Art Barstow

[1] <http://lists.w3.org/Archives/Public/public-device-apis/2009Apr/
0000.html>





________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.