RE: [waf] Draft of merged Web Apps WG charter available

Hi Art, all

(bcc'ing w3c-ac-forum)

Thanks for the very detailed response.  I understand that the W3C Team
has had reviews, but the Advisory Committee hasn't had a chance to
review the scope of the access control work.  I am not disappointed that
the WAF group is working on the AC-spec.  I'm disappointed: 1) that it
has progressed so far with little Advisory Committee review, 2) there
has been little work done on requirements and usage scenarios.  If I as
an AC rep had had a chance to review the charter of the work, I would
have said I'd like to see the scope of the work up front, which ought to
have included some of the tricky requirements that are still being
discussed.  We're now in a situtation where some people feel the Access
Control doc is ready to go to Last Call, but others have disagreed with
the fundamental requirements since their very first review.  The Team
never wrote up and published any requirements or a deliverable change
for the group, so their review and issues are opaque to me.  In my mind,
this is a significant part of why we have the W3C Process, to ensure
transparency and predictability in our process.  The current WAF charter
is water under the bridge as it has expired - though I observe that at
least one notable member of the WAF group hasn't bought into delivering
a reqs/usage scenarios - so it was the Web apps WG charter that my
review addressed.

I see the need to back up my claim that I see considerable evidence that
the specification has "flown low on the radar".  I didn't and don't make
the claim it has intentionally done so.  For backup, what I can point to
are a lack of pointers, rather than pointers.  Some of what I consider
missing pointers are:
1) the WAF home page [1] does not mention or link to the the work item
in the left hand deliverables pane, though the WD is linked from the
right hand side
2) the WAF charter page [2] does not mention the work item
3) the AC forum does not contain an announcement of the charter change
4) The Team reports on Rich Web Client Activity from the 2006 AC
meetings do not mention it.  I would have expected this to appear, even
just a simple line item saying "we added Access Control to WAF charter",
in the Nov 2006 meeting if not the May 2006.  It is mentioned in the May
and Nov 2007 team reports, but the Interaction slides from both meetings
aren't available online so I can't see if it was mentioned during the
presentation.  Even if it was mentioned, the Nov 2007 meeting was done a
little differently than before and some items could easily have been

Going forward, I think we agree that it's important that requirements
and usage scenarios are at least started and published early in the
life-cycle of the work.  I'm agin the out-dated waterfall approach, and
iterative development is preferable.  That should be done for each
deliverable in any chartered work, and any proposed additions to work
should be formally run by the AC.  I agree that one spec per WG can be
unmanageable, and I don't suggest that for Web applications.  I would
expect something like 2-4 WGs and maybe XGs to be preferable.  



> -----Original Message-----
> From: Arthur Barstow [] 
> Sent: Saturday, January 12, 2008 12:56 PM
> To: David Orchard
> Cc:
> Subject: Re: [waf] Draft of merged Web Apps WG charter available
> David, All,
> Regarding, why is the WAF WG working on the AC [AC-spec] 
> spec, I think some history is important -
> Our work began after the Team held a Project Review [AC-PR] 
> in April 2006. The review was chaired by Thomas Roessler and 
> the Chair of the AC task force (Brad Porter) presented slides 
> [Brad] that identified a small set of Use Cases that would be 
> in scope as well as the basic architecture of the proposed 
> work that was based on a related WG Note by the VB WG 
> [AC-Note]. A few weeks later Tim approved publication of the 
> the first WD.
> Clearly the Team could have blocked that FPWD pending an AC 
> review. I can't speak for them but based on the relatively 
> small set of UCs we identified at the time and the desire not 
> to have different competing specs (i.e. one for VB, one for 
> XBL2, one for XHR), the task/spec envisioned didn't seem 
> large enough to form a new WG. If we wanted to ignore other 
> UCs and prior work and just solely address WAF's AC- related 
> requirements i.e. XBL2, then we could have embedded something 
> like the AC spec directly in the XBL2 spec. If we had done 
> so, we wouldn't be discussing this issue (=is this work 
> explicit in the
> Charter) but don't think such a short-sighted position would 
> have been wise. Lastly, hindsight is always 20/20 and if we 
> were able to predict the future in April 2006 e.g. we knew 
> that new technologies such as JSONRequest could be 
> potentially relevant, then perhaps a different choice would 
> have been made.
> Regarding transparency i.e. the the implication this work was 
> intentionally "flown low on the radar screen" - I'm surprised 
> by this assertion because I've done what I believe is more 
> than due diligence to publicize this spec. In particular, 
> during the May 2006 AC meeting I made a presentation about 
> this work [AC-PR]. The work was also discussed or mentioned 
> in Domain reports or presentations at the May 2006, November 
> 2007 and May 2007 AC meetings. Additionally, I included an 
> overview of the spec in my WAF WG presentations at
> WWW2006 [WWW2006] and WWW2007 [WWW2007], in June 2007 we 
> explicitly asked the TAG to review the spec [TAG-Request], we 
> invited the WSC WG and XML Security Maintenance WG to our 
> TPAC f2f meeting, we have directly engaged with the POWDER WG 
> and this spec was also mentioned on several of the W3C's 
> Newsletters and NewsWires.
> Thus, I would appreciate it if you would please send me the pointer
> (s) to the evidence that substantiates your claim:
> [[
> I see considerable evidence that the specification has "flown 
> low on the radar"
> ]]
> Regarding the need for UCs and Requirements - as you know, I 
> agree with you (as I've stated on the WG's member and public 
> mail lists) and I appreciate you volunteering to help with 
> that task so thanks again.
> Regarding work item granularity for a WG - as Nokia's AC rep 
> I have at times struggled with the related issues including: 
> Team overhead, allocation of Nokia's resources, IPR concerns, 
> etc. It's a interesting balancing act and surely a single 
> spec (or spec family) per WG is appropriate at times but 
> could also introduce unacceptable overhead if taken to the extreme.
> BTW, during last November's TPAC meeting, I encouraged Hal to 
> join the WAF WG and explained to him that one reason we do 
> not enforce the Good Standing requirement is to facilitate 
> people like him that only want to participate on a specific spec.
> Regards, Art Barstow
> ---
> [AC-spec] <>
> [AC-PR] <>
> [AC-Note] <>
> [Brad] <>
> [WWW2006] <>
> [WWW2007] <>
> [TAG-Request] <
> 0114.html>
> On Jan 11, 2008, at 8:00 PM, ext David Orchard wrote:
> > I'm Bcc:ing the AC List because I believe that other AC 
> members may be
> > interested in my comments, but I don't want WG members to 
> accidentally
> > cc the AC list.
> >
> > My comments are mainly that the charter is too broad in 
> scope and too
> > undefined in deliverables.  The broadness of scope of the 
> current WAF
> > charter has precluded our organization from significantly  
> > participating
> > in the Working Group, and this rechartering exacerbates the problem
> > going forward.  In our case, Hal Lockhart is a supremely qualified
> > person to work on Access Control but has spent little time on that  
> > area
> > of work because the current WAF is so broad in scope.  In another
> > example, we have other people who are qualified and 
> interested in the
> > Widgets work but are unable to participate for the same reasons.
> >
> > The usual solution for the problem of a very broad scope in 
> charter is
> > to refactor into more WGs with smaller charters.  I prefer 
> that but  
> > I'm
> > also open to other solutions that increase the participation in
> > deliverying items under the W3C Process.  I'm very 
> uncomfortable with
> > the current charter scope and single WG process.
> >
> > As an example of the problems of broad and open scope, I am  
> > disappointed
> > by the way that Access Control was added to the Working Groups
> > deliverables without AC review and the usual deliverables of
> > requirements and use cases.  It seems that almost 
> immediately after  
> > WAF
> > was chartered [1] in November 2005, it immediately took over  
> > editing the
> > "Authorizing Read Access to XML Content Using the <?access-control?>
> > Processing Instruction 1.0" document, as roughly described 
> in [2].  I
> > realize that the charter says "Given that the rich Web client area  
> > is in
> > a phase of rapid development, the Working Group may become 
> aware of  
> > the
> > urgent need for standardization of a technology not explicitly  
> > listed in
> > this charter, but still in the scope of the Working Group", 
> but I fail
> > to see why such urgency that an AC review and normal process can be
> > ignored.  In the Access Control case, it was added almost 
> immediately
> > after chartering in December 2005 and has been worked on 
> sporadically
> > since then and we are now at January 2008.  I see considerable  
> > evidence
> > that the specification has "flown low on the radar" and there are  
> > still
> > many differences of opinion about fundamental requirements. 
>  AC review
> > and publication of Requirements and Use Cases are good triggers for
> > early review and consensus building, and we did not see those.  This
> > lack of process on Access Control has meant that we have not  
> > tracked the
> > work nearly as closely as we would have liked, though we are now  
> > trying
> > to rectify that.
> >
> > I would like the AC consulted whenever a deliverable is 
> added.  I'd  
> > like
> > to see a more rigorous process that includes early publication of
> > requirements and use cases for each deliverable.
> >
> > Cheers,
> > Dave
> >
> > [1]
> > [2]
> > 
> > 0004.html

Received on Thursday, 24 January 2008 18:56:38 UTC