[saga-rg] Revised SAGA-RG charter

[Steven Newhouse]

I've made some changes for typos inline... with a few other comments for 
consideration.

Steven

>  The Charter
> 
>  Informational Section
>  ---------------------
> 
>   Area:           Applications [Standards]
> 
>   Name of group:  Simple API for Grid Applications
> 
>   Acronym:        SAGA RG
> 
>   Type of group:  Reasearch Group (RG)
> 
>   Chairs:         Tom Goodale, Shantenu Jha, Thilo Kielmann
> 
>   Secretaries:    TBD
> 
>   Email list:     saga-rg at ggf.org
> 
>   Web page:       http://forge.ggf.org/projects/saga-rg/
> 
> 
>  Charter:
>  -------
> 
>     This charter is the result of a re-chartering of the SAGA Research
>     Group.
> 
>     Focus/Purpose:
>     -------------
> 
>     Many application developers wish to make use of the exciting
>     possibilities opened up by the advent of the Grid.  Application
>     developers, however, have their own agendas to pursue and often
>     cannot spare the time or resources to fully investigate the vast
>     wealth of Grid technologies and APIs which currently exist.  They
>     would rather be presented with a simple API close to the
>     programming paradigms and interfaces they are used to.
> 
>     For example, the process of copying of a remote file may involve
>     interaction with a replica location service, a data transport
>     service, a resource management service, and a security service.
>     It may involve communication via LDAP/LDIF, GRAM, HTTP, and GSI,
>     as protocols or protocol extensions. A Fortran application
>     programmer,  however, wants to see a call very much like:
> 
>           call fileCopy (source, destination)
> 
>     Although this example is simplified, it illustrates the motivation
>     for our work. The APIs specified by this RG will deliver a similar

The RG is not specifying APIs IMHO. Suggest you use, developed or
identified instead.

>     level of abstraction for a range of basic operations which need to
>     be grid aware.  The precise set of operations is to be decided by
>     the RG based upon application requirements and use cases; examples
>     of such operations may be file access, job submission, monitoring
>     or steering.
> 
>     The group will lower the barrier for application developers to
>     make use of the grid by providing a small, consistent API for the
>     operations of interest, the Simple API for Grid Applications
>     (SAGA).

I'd suggest cutting the previous paragraph. This is the role of the
spawned WGs. The RG is the coordinating activity which comes across well
elsewhere.

>     Scope:
>     -----
> 
>     The group will build on the results and feedback of the work of
>     the former SAGA RG.  As such, it will provide a forum in GGF to
>     consolidate application driven API specifications.  The primary
>     goals of the group are two fold:
> 
>     1) provide general guidlines for application driven API
>        specifications in GGF (security guidlines, common look & feel,
>        interoperability guidlines, conflict resolution, etc.)
> 
>     2) The group will form, on an ad hoc basis, design teams
>        which investigate new API areas for inclusion in the SAGA-API
>        The design teams are supposed to

Change to: The design teams will

>         - solicit related application use cases
>         - issue an informal use case document
>         - issue and informal requirement document

Typo:     - issue an informal requirement document

Question: Do you mean informal or informational? Several of the OGSA
design teams have captured their work in informational documents. This
may be a good idea?

>     3) Spawn off focused working groups which will work on API
>        specifications (standard recommendation track) for specific
>        subsystems, e.g. RPC, CPR, application steering etc, after
>        a design team has identified and explored an area as described
>        in (2) above.
> 
>     4) Coordinate the activities of the SAGA working groups and
>        make sure that the resulting APIs are in line with the
>        SAGA goals.
> 
>     The SAGA API does not strive to replace globus or
globus -> Globus
>     similar middlerware systems, and does not target middlware
middlerware -> middleware
>     developers, but solely application developers with no assumed
>     background on Grid Computing who wish to grid enable their
>     applications whilst spending as little time as possible learning
>     new paradigms.  Such developers typically wish to devote their
>     time to their own goals and minimise the time spent coding
>     infrastructure functionality. The API will insulate application
>     developers from middleware.
>
Commas in the following sentence.
>     The specification of services, and the protocols to interact with
>     them, is out of the scope of the WG.  Rather, the API seeks to hide
>     the detail of any service infrastructures that may or may not
>     exist to implement the functionality that the application
exist -> be used
>     developer needs. The RG will, however, actively liase with all
all -> relevant
>     grid-middleware groups within the GGF to ensure compatability.

Is compatability the right word? You're not defining an implementation 
but the specifications being produced in GGF and elsewhere that you are 
going to build upon.

> 
> 
>     Exit Strategy:
>     --------------
> 
>     No clear exit strategy for this group exists, as it is supposed to
>     provide means to continously spawn off focused working groups.
>     However, the group does have a list of deliverables, and should
>     revisit its charter after these deliverables have been completed.
> 
> 
>     Goals:
>     ------
> 
>     Note: As this charter is a result of a re-chartering process for
>     the SAGA RG, it also contains goals and deliverables which already
>     have been delivered, or are currently in the process of beeing
beeing -> being
>     deliverd.
> 
>     The group will produce an informal use case document ("SAGA
>     Use-Case Document") and a informal requirement document ("SAGA
>     Requirements Document").
> 
>     In continuation, and broadening its scope, the group will create a
>     Community Practice Document "SAGA API Guidlines", which will
>     define the Look & Feel of SAGA APIs, and describe central
>     paradigms (such as asynchroneous operations and error handling)
>     which should be respected in SAGA API specifications.  That
>     document will build upon the experience of the SAGA-CORE WG and their
>     initial SAGA API specification v1.0.
> 
>     These documents are to guide the spawned off working
>     groups, and to ensure short and concise working agendas for these
>     groups.  The formation of design teams is informell, and should
informell -> informal
>     always strive to find members from the specific areas of
>     expertese - i.e. members from the relevant GGF community groups,
expertese -> expertise
>     and members from the relevant GGF standards groups.
> 
> 
>     * Informational Document:
>       "SAGA Use Case Document"
>       - use cases
> 
>     * Informational Document:
>       "SAGA Requirements document"
>       - define exact scope of the initial SAGA API
>       - define target user groups for initial SAGA API
>       - define programming languages to be supported by the initial
>         SAGA API
> 
>     * Informational Document:
>        "SAGA compatability with other Grid specifications"
See my earlier comments - "SAGA use of other Grid specifications"
>         This document will survey the compatability of SAGA
>         reference implementations with underlying models of
>         grid-middleware including, but not confined to OGSA.
> 
> 
>     * Community Practice Document:
>        "SAGA API Guidlines"
>        This document will define the Look & Feel of SAGA APIs,
>        and describe central paradigms (such as asynchroneous
>        operations and error handling) which should be respected
>        in SAGA API specifications.
> 
>     Milestones:
>     -----------
> 
>     GGF16: - Finalization of "SAGA Use Case Document, version 1"
>            - Presentation of "SAGA Requirements document, version 1"
> 
>     GGF17: - Finalization of "SAGA Requirements document, version 1"
> 
>     GGF19: - Presentation of "SAGA compatibility with other Grid
>                               specifications, version 1"
> 


-- 
----------------------------------------------------------------
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