Andreas,
    We didn't have a discussion on this in our weekly call.   As Karl and Toshi noted  that this is a trivial change (and Heiko provided a validated schema with this change), so from a pure technical implementation viewpoint this doesn't impact  the spec even at this late stage.  

I believe this is a very important issue, and we should have a well reasoned and well articulated position on this for the wider audience -- whatever may be the final decision of the group.  The issue will keep coming up as the wider audience (Web Services community) will fail to grasp the strong objections of this group to aligning this spec to WS* stack, and WS-Policy in particular.  I believe the goal of this group is to make WS-Agreement  specification to be adopted by the wider Web Services community, and not to be perceived as something niche for job scheduling or just "Grid-thingy".   Off course, in the same spirit, I (we) have equally strongly advocated to the JSDL community for leveraging this spec in specifying flexible scheduling objectives.

There are several benefits from this change: better alignment and acceptance by the broader WS* community and also avoiding confusion on SLA vs Policy.  A wide spectrum of folks I hear from in my everyday activities (architects, developers, customers, analysts...)  don't quite distinguish SLA and Policy.   [ Off course, that's not my position.]  Typical comments I hear -- are you using WS-Policy  in specifying service level assertions?  By embracing the use of WS-Policy as an envelope for agreement terms we not only avoid this confusion but also easily demonstrate what additional aspects are being covered by WS-Ag spec.  Finally, in the runtime enforcement environments (service registry, monitoring system, workload manager, ... ) SLA derived enforcement policies can be represented uniformly.

Given that WS-Policy draft (that has been submitted to W3C) is very stable - has been co-authored by representatives from several organizations, already implemented by many vendors and many other OASIS standards on security, transaction, reliability, etc. dependent on this spec -  and changes to the current draft of WS-Ag spec is minimal (not surprising, since we started with WS-Policy for term composition), there are many good reasons to embrace WS-Policy now. In any case, it's a public document (W3C), and we can make WS-Ag   spec dependent only on the submitted draft.

Regards.
Asit Dan, Ph.D.
SWG SOA Design Requirements
Phone: (914) 766-1767  
Internet: asit@us.ibm.com
ICSOC 06 PC Chair (http://www.icsoc.org)


Karl Czajkowski <karlcz@univa.com>
Sent by: owner-graap-wg@ggf.org

06/28/2006 03:20 AM

To
Andreas Savva <andreas.savva@jp.fujitsu.com>
cc
"'GRAAP-WG'" <graap-wg@gridforum.org>, Toshiyuki Nakata <t-nakata@cw.jp.nec.com>, Asit Dan/Watson/IBM@IBMUS
Subject
Re: [graap-wg] url for the Web Services Policy WG in W3C





I agree. It doesn't seem to add much to WS-Agreement at this point,
and I think people who want to engage in an "SLA and policy"
discussion should be able to observe the trivial mapping necessary
to understand our compositions as policy composition.

karl


On Jun 28, Andreas Savva modulated:
...
> I've read Toshi's previous email on pros/cons and I agree with him. I
> think at this point (one step before publication of the WS-Agreement
> spec) making a change that brings back a dependency on a specification
> that is about to enter the standardization process is not a good idea.
>
> --
> Andreas Savva
>

--
Karl Czajkowski
karlcz@univa.com