Re: Draft Charter for a Device API and Security WG

Hi Robin,

The changes you propose below are OK with me. A few follow-ups

Re availability of test suites - I believe I C&P'ed that text from  
WebApps' Charter. I think the use of "should" gives the group some  
flexibility. Ideally, I think having a test suite at the end of LCWD  
would be good but I agree that in practice creating the test cases  
during the CR phase is more likely to happen.

Re the "Device API Design Patterns" work item - that was proposed by  
Marcin so we should his feedback. Marcin? I'm mostly indifferent as  
to whether it is Normative or non-Normative and if there is consensus  
it should be non-Normative that is OK with me.

Re the milestones table - a Charter is required to include "expected  
milestones [1]". I think this is important information to set  
expectations for Members and the Public (even though we all realize  
that "stuff happens") and to help Members during their decision  
process about joining a WG.

Dom or Philipp - I assume someone from the Team will now take over  
the editing of this Draft charter.

-Regards, Art Barstow

[1] <http://www.w3.org/2005/10/Process-20051014/groups.html#WGCharter>


On May 12, 2009, at 11:07 AM, ext Robin Berjon wrote:

> Hi Art, all,
>
> here are comments on your charter proposal on behalf of Vodafone.
>
> On May 11, 2009, at 12:37 , Arthur Barstow wrote:
>> Attached is a new Draft charter for a single WG to define both the
>> Device Service APIs and Security Policy work we've been discussing
>> (as a result of the December 2008 Workshop) [1].
>
> By and large we support this charter, and fully intend to commit
> resources to this WG once it has been ratified. We would like to urge
> the team to move with haste on the creation of this WG. We are also
> glad to note that the WG is intended to operate in public.
>
> Editorial: I wouldn't include "All of the API specifications will use
> Web IDL to describe the API." I agree with the statement but it's too
> restrictive to be in a charter.
>
> Substantial: We are not wild about the "Device API Design Patterns".
> The timeline puts it on Rec track which we doubt is useful. We agree
> that making the APIs consistent amongst themselves is desirable, and
> that documenting the decisions we made is useful for the community at
> large, but there should be no normative dependency on such a document
> and it shouldn't be on the critical path — we've done APIs before
> without it. We therefore propose that this document be developed on
> the side (i.e. not before the others) and be a Note, not a Rec.
>
> Editorial: Do the PIM APIs need to be grouped? It appears that they
> could probably just be used separately, like any of the other APIs.
>
> Editorial: We would like it to be clear that the WG may produce
> multiple versions of an API, and that the plan is to push out
> consensual, technically simple APIs fast, and build on top of those to
> add features that may take more time to define and reach agreement on.
>
> Substantial: Do we really want to have test suites ready for the end
> of LC? The usual is CR. We don't necessarily object, but the effect
> might simply be to lengthen LC and shorten CR.
>
> Substantial: While we realise that charters are expected to contain
> dates picked out of a hat in a table called "Milestones", and that
> documents will subsequently be released on any date except those
> chartered, we do have some concerns about the underlying assumptions
> that may have guided the this particular "Milestones" table. First and
> foremost it seems to put the DAPIDP document before the rest, as if a
> primacy and dependency were intended — as outlined above we do not
> believe that this would constitute the best use of the WG's time.
> Another concern is that the API specifications appear to move in
> perfect unison, which is both unrealistic and undesirable. We propose
> that this table be removed, and replaced with text indicating that: 1)
> DAPIDP is expected to be developed as needed on a voluntary basis and
> may be (re)published as a Note at irregular intervals, 2) that all
> documents will have reached Rec before the end of the charter, and 3)
> that otherwise the WG will control the timing of it releases, and may
> for instance identify a subset of its work as high-priority and decide
> to fast-track it. It is our belief that this better reflects what will
> actually happen irrespective of what the charter looks like — so we
> might as well be honest up front.
>
> Editorial: In the interest of helping our community find us, we
> suggest that the group's page not be in a dated URI.
>
> Other than that, it's all good.
>
> -- 
> Robin Berjon - http://berjon.com/
>      Feel like hiring me? Go to http://robineko.com/
>
>

Received on Tuesday, 12 May 2009 18:38:06 UTC