I'll try and provide factual responses rather than opinions! BUt I expect I'll fail.
-- If the lack of focus is a concern (as has been expressed on this list and privately by some parts of the community), can that not be effectively addressed without spawning?
The current WG charter does not scope what it would explicitly do. If another group came along to do an API for X, the SAGA-WG _could_ say they it was within their scope. This is simple to fix by... Explicitly, scoping the proposed SAGA-WG activities would produce a list. A long list or a short list is in the eye of the beholder. But a question that would have to be answered why is this list of activities (API area) all part of one WG? The reason from SAGA is that there needs to be co-ordination - which I think there is general agreement about there is a need for this. The question IMHO is how to deliver this co-ordination. This appears to be the issue.
Also, spawning groups in itself isn't a guarantee of focus or simplicity. Spawning groups has a resultant high risk possibility that the spawned subgroups make each subsystem too exhaustive. Not that it can't happen with a single group, but just that the temptation is less acute. Similarly, might not each sub-group still end up losing focus (with the added overhead that fragmentation involves)?
A WG has a specific set of explicit deliverables/milestones that reigns it in. WG creep is monitored and controlled by the AD's and the GFSG.
-- In addition to concerns about the exact working relationship issues, a MAJOR fear that I have is that spawning groups might just be a symmetry-breaking event, i.e., where the common look-and-feel might be lost forever and will be irrecoverable in spite of an umbrella SAGA-RG.
Each WG has a remit to produce something. The 'umbrella' group looks at taking the output from the WG and ingesting it to ensure that it 'works'. The umbrella group has a lobbying obligation on the WG to make sure it fits. If the WG activity is well defined (informed form the RG activity) this should not be an issue.
SAGA is a meant to be a single consistent API. Might help to go back to the the MPI analogy. Did different parts of the MPI specification process evolve under distinct working groups? Or did the different 'sub-systems' evolve together? Why?
MPI (AFAIK) was put together by sub-groups (point 2 point, collective, etc.) working in isolation and then syncing up to be consistent.
-- EXACT working relationship between umbrella SAGA-RG and spawned SAGA-WGs?
For OGSA the spawned WGs are asked to join the OGSA telecons & the F2F to report on progress. There is a two way communication. A WG given an OGSA prefix has a 'responsibility' to engage in this. It should be (is) in their charter to do so... I believe.
-- Assuming SAGA goes with the spawning approach: What are the necessary conditions to spawn future groups? e.g., must each subsystem get its own WG? What are the sufficient conditions?
If its an identifiable scoped bit of work it should IMHO be in a WG.
-- At the risk of opening a whole new can-of-worms and that too a rather polemical one: Is the Go-henceforth-and-spawn suggestion a proxy to align SAGA more intimately with OGSA?
On a one-to-one level... no in my view. Its a model. The SAGA job submission activity might use the OGSA-BES and ByteIO services as part of one implementation, or WS-GRAM and RFT as part of another implementation.
What does, "SAGA being the public-face of OGSA" mean and imply?
SAGA being the higher-level API that an application developer might use to access service infrastructure, ONE implementation of that API would use the OGSA-* services.
Whereas I'm all for the alignment of SAGA and OGSA (even more if as has been said, "SAGA is the application area flagship of the GGF"), is there a premature and/or even an over emphasis on "aligning" SAGA and OGSA? If so, is this in the best interest of OGSA? SAGA? or GGF as a whole?
Alignment - OK. Tied exclusively too - not OK.
-- "Some concern was expressed about focus and broad scope. Especially as other domains would like to bring forward their own domains (data access, data movement, etc) for client side API standardisation."
I'm sure there is more to it than the following, but as a simpler first step, why can't we have more sanity checks with such domains e.g., http://www-unix.gridforum.org/mail_archive/saga-rg/2005/10/msg00017.html Doesn't approach appears to be working for DRMAA, GridRPC and GridCPR, if not data movement?
The RG spawning WG model would IMHO do that. These are all tightly scoped WGs.
-- In the case of a split opinion, how does the group make the final call?
AFAIK... the final call MUST go to the list. Rough consensus is the phrase... what that means in practice... has to be seen. Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Director, Open Middleware Infrastructure Institute-UK (OMII-UK) c/o Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK