RE: ISSUE-5: Application Configuration API

I agree, an overall document would be the best place to capture common aspects. One of the good things about the Widgets specs is that they introduce the reader to the overall subject including a landscape document and a requirements document. The reader who finishes these (which does not take too long) should be ready to dive into the specific Widgets specs and have a better understanding of the context of each spec as it fits into the overall Widgets spec package.

I'm not proposing both a landscape and requirements document, or specifically either, but an umbrella document which makes it possible for the reader to assess:
- how the API specs (and other common specs e.g. an API patterns spec) fit into the overall web application context
- why certain things are addressed in the DAP spec suite
- why other specific things are not

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: Frederick Hirsch [] 
Sent: Wednesday, September 23, 2009 10:02 AM
To: ext
Cc: Frederick Hirsch; SULLIVAN, BRYAN L (ATTCINW);
Subject: Re: ISSUE-5: Application Configuration API


We might also consider having a separate common document applicable to  
all APIs, whether common API specification, and/or requirements. This  
might be sensible to avoid replicating material and introducing errors  
in doing so, as well as addressing commonly applicable concerns. As I  
mentioned in other email, we should be able to communicate outside the  
WG and after the WG completes - implicit decisions/assumptions will  
not be clear.

This need not be a heavy-weight document, and only need highlight  
items all should be aware of across the board.

We can also reference to it from the specs, easily using Robin's  
bibliographic database approach.

What do you think?

regards, Frederick [sent not as chair]

Frederick Hirsch

On Sep 23, 2009, at 12:30 PM, ext  

> Hi Bryan,
> Agreed we need a note if we drop things from our charter. The same  
> would be true if our charter needed to grow at any point (e.g. if we  
> decided we need to add additional APIs in the future).
> We should therefore have a process for dealing with both of these  
> events as this problem could crop up again. My understanding of W3C  
> process is that a charter can be changed with membership consent but  
> I would be interested in clarification.
> Anyway, failing a straightforward change to the charter, there are a  
> few other options for including the required note. Such as:
> - an addendum to the charter (though perhaps this would be subject  
> to the same rules as changing the charter itself?).
> - a DAP Primer/Introduction W3C Note (as suggested by Bryan and  
> Kangchan on the call)
> - an 'empty' App Config API spec with the following words: 'The  
> Application Configuration API was not addressed as detailed in the  
> W3C DAP charter because...'
> My preference would be to change the charter directly if at all  
> possible or include the note as an addendum to the existing charter.
> Best Regards,
> Richard Tibbett
>> -----Original Message-----
>> From:
>> [] On Behalf Of
>> Sent: 23 September 2009 16:11
>> To:
>> Subject: RE: ISSUE-5: Application Configuration API
>> As noted on the call today, we need to provide a documented
>> rationale why we are not addressing the application settings
>> functionality that were included in the charter as
>> "Application Configuration API". I am OK with not addressing
>> an Application Configuration API given that we clarify that
>> the existing work on localStorage in HTML5 and referenced by
>> the Widgets specs meets the intent of the Application
>> Configuration API. But we should at least make that note in
>> some document we produce, so readers are not confused as to
>> why we have remained silent on something that was part of our
>> original charter. We could produce either a W3C Note or a
>> make a scope section note in an umbrella Requirements
>> document to this effect. Given that the publication of a
>> Requirements document is itself an open question, we should
>> at least do this via a W3C Note (e.g. the "Primer" mentioned
>> by Kangchan). Since such a document will be important anyway
>> IMO for the developers/deployers of the overall set of API
>> and Policy specifications that DAP produces.
>> Best regards,
>> Bryan Sullivan | AT&T
>> -----Original Message-----
>> From:
>> [] On Behalf Of Arve
>> Bersvendsen
>> Sent: Wednesday, September 23, 2009 3:13 AM
>> To:
>> Subject: ISSUE-5: Application Configuration API
>> I'd like to propose that we drop the "Application configuration API"
>> deliverable from this group's list of deliverables.
>> 1. Application preferences are already covered by the Widgets
>> 1.0 P&C and "Widgets 1.0: The widget Interface"
>> 2. Data persistence APIs are also covered by the (HTML5)
>> WebStorage spec (and for more complex cases, WebDatabase)
>> --
>> Arve Bersvendsen
>> Opera Software ASA,

Received on Wednesday, 23 September 2009 19:22:54 UTC