Re: Updated charter proposal

On Mon, Jun 4, 2012 at 11:04 AM, Carr, Wayne <wayne.carr@intel.com> wrote:
> If it turns out editors from various previous efforts at creating an api on some topic want to work together in consolidating that api, why stop them?

For the same reasons we've discussed before, namely that the working
group needs some focus in order to produce a coherent set of
high-quality specifications.  I've said this before, but spamming the
working group with FPWD isn't a path to success.  It's a path to a
bunch of low-quality specs.  The path to success is agree on basic
things first, get multiple folks to implement the same specs, and then
iterate.

Adam


> DAP has to worry about fingerprinting and also users surfing to random websites where accidentally saying yes, when they mean no, could be bad.  So their APIs in these areas are restricted or absent.  E.g. you can ask to see a contact, but you can't write an editor for contacts.  That's why there is overlap with DAP, but it is for features that DAP chooses not to support but that are supported in a typical app on and OS. It seems you have dropped quite a few specs.  We would want to discuss which, if any, specs are dropped on a spec by spec basis.
>
>>Yes.  The group's IPR commitments cover all deliverables, regardless of which
>>phase they're in.
>
> Eventually, it does, but not until you get to First Public Working Draft so not for a while for phase 2.
>
>>-----Original Message-----
>>From: Adam Barth [mailto:w3c@adambarth.com]
>>Sent: Sunday, June 03, 2012 9:41 AM
>>To: SULLIVAN, BRYAN L
>>Cc: public-sysapps@w3.org
>>Subject: Re: Updated charter proposal
>>
>>On Sun, Jun 3, 2012 at 9:24 AM, SULLIVAN, BRYAN L <bs3131@att.com> wrote:
>>> So to better understand the "phase 2" designation, if we find that the parties
>>involved are quicker than expected to buy into the process and see the benefit of
>>a standard, how does a phase 2 deliverable move into active discussion (can a
>>specific spec move onto the main stage prior to the overall set of specs in phase
>>2)?
>>
>>The chairs issue a Call for Consensus to publish a First Public Working Draft of the
>>document, just the same as with any other deliverable.  The charter just asks the
>>working group to make some substantive progress on some of the phase 1
>>deliverables before diving into phase 2 work.  There's no requirement to
>>complete phase 1 before working on phase 2 deliverables.
>>
>>> Would a phase 2 designation still allow a pre-WD spec (or multiple of them) to
>>be worked on under the group's umbrella? At least that would provide some
>>visibility to the current proposals as they converge, prior to the spec advancing to
>>the main stage.
>>
>>
>>Yes.  The group's IPR commitments cover all deliverables, regardless of which
>>phase they're in.  It's up to the chairs to decide which discussions are "on topic"
>>for the mailing list.  If I were chair, I would certainly encourage such discussions,
>>but I would stop short of trying to hammer out a consensus until I thought the
>>parties were ready.
>>
>>Adam
>>
>>
>>> -----Original Message-----
>>> From: Adam Barth [mailto:w3c@adambarth.com]
>>> Sent: Sunday, June 03, 2012 9:06 AM
>>> To: SULLIVAN, BRYAN L
>>> Cc: public-sysapps@w3.org
>>> Subject: Re: Updated charter proposal
>>>
>>> Indeed.  That's why it's included in the charter.  To resolve the
>>> issue, however, we'll need the parties involved to have bought into
>>> the process and to see the benefit of coming to a common solution.
>>> That's more likely to happen after they've worked together
>>> successfully on some of the less contentious specs, which is why I've
>>> put Media Storage in phase 2.
>>>
>>> Adam
>>>
>>>
>>> On Sun, Jun 3, 2012 at 8:59 AM, SULLIVAN, BRYAN L <bs3131@att.com> wrote:
>>>> I actually have been following the discussion and (think) I have a grasp on the
>>context.
>>>>
>>>> I support efforts to bridge the existing proposals through discussion in the
>>group. Media storage is one of the key gaps in being able to support offline and
>>cached use cases for stored media, as browser-based storage is ineffective for
>>that (too large content). I also believe that the File API's security model is too
>>manual (user-centric) but I support discussions about its use in a more persistent
>>permission system, enabling persistent access to for example a "videos" storage
>>location. Thus as a basis for the media storage API, it may have potential.
>>>>
>>>> But overall, where there are existing APIs in development across multiple
>>platforms (at least four I think), it seems to me there is clear market interest and
>>the time is right for W3C to broker a standard from these.
>>>>
>>>> Thanks,
>>>> Bryan Sullivan
>>>>
>>>> -----Original Message-----
>>>> From: Adam Barth [mailto:w3c@adambarth.com]
>>>> Sent: Sunday, June 03, 2012 8:30 AM
>>>> To: SULLIVAN, BRYAN L
>>>> Cc: public-sysapps@w3.org
>>>> Subject: Re: Updated charter proposal
>>>>
>>>> That's a generous offer, but I don't think structuring the discussion
>>>> that way will help much in the immediate term.  I'm happy to
>>>> discussion the history of this issue off-list if you'd like to
>>>> understand more of the context.
>>>>
>>>> Adam
>>>>
>>>>
>>>> On Sun, Jun 3, 2012 at 6:53 AM, SULLIVAN, BRYAN L <bs3131@att.com>
>>wrote:
>>>>> I suggest if the common ground at this stage of the discussion may be that
>>the Media Storage API could depend on the File API and its related APIs (for
>>argument's sake, if those that think otherwise are willing to consider this), that
>>we start with the assumption (if necessary, stated) that we will base APIs where
>>possible on existing APIs of similar type (e.g. storage access). That would allow us
>>to start the discussion of a specific Media Storage API, attempting to extend the
>>File API ala whatever "depends upon" means, and not defer that discussion to
>>some unspecified future date.
>>>>>
>>>>> As stated, we would be willing to contribute directly and co-edit if needed,
>>regardless of the design approach that is pursued. So we are willing to get started
>>on this API now.
>>>>>
>>>>> Thanks,
>>>>> Bryan Sullivan
>>>>>
>>>>> -----Original Message-----
>>>>> From: Adam Barth [mailto:w3c@adambarth.com]
>>>>> Sent: Sunday, June 03, 2012 2:19 AM
>>>>> To: public-sysapps@w3.org
>>>>> Subject: Updated charter proposal
>>>>>
>>>>> Hi SysApps,
>>>>>
>>>>> Based on the discussion on this list, I've put together an updated
>>>>> proposal for a charter:
>>>>>
>>>>> http://abarth.github.com/websec/drafts/sysapps-charter.html
>>>>>
>>>>> In addition to fixing a couple typos, I've removed the term
>>>>> "browse-by web" as discussed in
>>>>> <http://lists.w3.org/Archives/Public/public-sysapps/2012May/0028.html>.
>>>>>  I've also re-worked the deliverables section a bit.  I've split the
>>>>> deliverables into two phases, as discussed in
>>>>> <http://lists.w3.org/Archives/Public/public-sysapps/2012May/0002.html>.
>>>>>  I've also added the following paragraph to explain the distinction
>>>>> between these phases:
>>>>>
>>>>> ---8<---
>>>>> The working group's deliverables are divided into two phases.
>>>>> Initially, the working group will focus on deliverables in the first
>>>>> phase in order to establish patterns and conventions that will be
>>>>> used for the remaining deliverables. The working group does not
>>>>> necessarily need to complete work on the phase 1 deliverables before
>>>>> working on deliverables in phase 2. However, the working group
>>>>> should make some substantial progress on some of the phase 1
>>>>> deliverables before working on phase 2 deliverables.
>>>>> --->8---
>>>>>
>>>>> I was able to accomodate most of the requests folks sent to the list.
>>>>> The notable exceptions are Sensors, Calendar, and Contacts, all of
>>>>> which are deliverables for the Device APIs working group.  I'd like
>>>>> to avoid (or at least delay) a "territory" fight with that working group.
>>>>>  The charter has 16 deliverables, which is more than enough to keep
>>>>> us busy for two years.  I've also left NFC off the list because it
>>>>> had already been removed from the W3C version of the charter and
>>>>> seems likely to be taken up by the Near Field Communications working group.
>>>>>
>>>>> Despite strong interest on the mailing list, I've placed the Media
>>>>> Storage API in phase 2.  I think everyone agrees that Media Storage
>>>>> is an important API, but the issue is that there is strong
>>>>> disagreement about whether the API should depend on
>>>>> <http://www.w3.org/TR/file-system-api/>.  This working group will be
>>>>> the appropriate venue to have that discussion, but starting off with
>>>>> that discussion before we've all developed working relationships
>>>>> runs the risk of derailing the working group.  For that reason, I'd
>>>>> like to gather some momentum on some of the less contentious specs
>>>>> before opening that can of worms.
>>>>>
>>>>> Please let me know if you have any feedback.
>>>>>
>>>>> Many thanks,
>>>>> Adam
>>>>>
>

Received on Monday, 4 June 2012 18:59:58 UTC