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
