Re: Items not listed as "new" in the draft charter

Hi, Maciej-

I'm a little frustrated to be having this conversation now, after I 
tried for several weeks to get comments on the charter before sending it 
to W3M, and then to the AC.  There was substantial discussion on both 
the member-only list and on this public list (which you engaged in), and 
the appropriate time to raise these issues was then.

I agree with the goal of transparency, but the chief rationale for a 
charter is as an overview, not as a detailed history or exhaustive scope 
delineation; that is what the links to the documents themselves are for 
(where those are available).  It is unusual to be asked to go into this 
level of detail in the scope of a chartering review in the AC, and I 
haven't seen evidence that others share your concerns.  I am extremely 
reluctant to establish a precedent here, when rechartering is already a 
major pain.

We all know that the ultimate scope of a specification is defined 
throughout the ongoing process within the group itself, with different 
parties contributing to and steering the precise scope of the spec. 
Questions of scope are not settled in fine detail in the AC, but in the 
group itself.

So, precision in a charter is good, because it can help prevent too much 
scope creep, but where it interferes with the natural development of a 
spec or a group's work, then that precision is counterproductive.

For example, I made a mistake in the previous charter by relying too 
heavily on the descriptions of specs from their abstracts, while the 
group as a whole did not have consensus on the scope of those 
deliverables.  In the examples you cite here, I was too precise: the Web 
Database one (where we all agreed that we wanted the functionality, but 
had disagreement on whether it would be based on SQL or B-Trees); and 
the secure cross-domain scripting one (where there are disagreements 
about the mechanism).  I was glad to be given the opportunity to correct 
those mistakes.

Based on my exegesis of the email discussions and history of the specs 
themselves, I think the wiki page is factual and neutral, and if 
necessary, I am willing to go into detail about why I reached these 
conclusions (I'm reluctant to go into such detail here because of the 
time it would take, and everyone is free to reads back through the 
sources, since it's all public).  Splitting hairs is arguably less 
forthright, because it would impose a particular viewpoint on the 
history of these specs, drawing more attention to certain deliverables, 
with potentially disruptive consequences... that is, reviewers may think 
certain deliverables are more controversial than they really are, and 
vote against the charter on that basis; for example, the Indexed DB spec 
seems more popular than the Web SQL DB, but pointing out that it is 
somewhat different than the originally defined scope would misrepresent 
its position.

Regarding differences between the descriptions of this charter and the 
last, that is precisely what a rechartering is for: to better describe 
the current state and focus of the deliverables as they have changed 
over time.  The previous (existing) charter is available for comparison, 
for those who are interested.

Perhaps at this point, if you have specific changes you would like made, 
it would be best to have your AC rep describe them in the normal course 
of AC review, or to discuss them in the AC forum?

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Maciej Stachowiak wrote (on 3/29/10 2:40 PM):
>
> On Mar 29, 2010, at 10:22 AM, Doug Schepers wrote:
>
>> Hi, Folks-
>>
>> I've put together a wiki page [1] that I propose to send to the AC as
>> a further clarification on the charter discussion. How does this look
>> to you?
>>
>> Does everyone agree that this is fair representation of the changed
>> work in the WebApps WG charter?
>>
>> [1] http://www.w3.org/2008/webapps/wiki/Charter
>
>
> More comments:
>
> It may be worth noting that some of the deliverables described as
> alternate proposals do not actually match the charter descriptions for
> the previous main deliverables. For example, the 2008 charter describes
> CORS thus:
> "A mechanism for selective and secure cross-domain scripting (formerly
> Access Control for Cross-site Requests)."
>
> But UMP is arguably not "selective"; it lets you limit what resources
> can be access cross-domain, but not who can access them, by design.
>
>
> The 2008 charter describes Web Storage thus:
> "Two APIs for client-side data storage in Web applications: a name-value
> pair system, and a database system with a SQL frontend."
>
> But Indexed Database clearly does not really satisfy the description of
> either of those two APIs, again, by design.
>
>
> I think it's better to be forthright about this. The whole reason these
> APIs exist is to differ in a fundamental way from the other relevant
> charter deliverables in a fundamental way.
>
>
> I also disagree with both describing Widget Embedding as new, and then
> also describing it as split from another document. It was certainly not
> split from anything published under the 2008 charter; rather it is
> apparently based on a section heading of an empty section from a draft
> published in 2007. Since it's already listed as new, I don't think
> further explanation is needed, and would rather just see it listed as
> new without comment than to debate its historical origins. Or I would be
> fine with a note that it's based on concepts that preceded the 2008
> charter period.
>
>
> Regards,
> Maciej
>
>

Received on Tuesday, 30 March 2010 00:25:41 UTC