Jon McLaren asked why the specification should be dependent on WSRF  
to express the Web service interfaces in WS-Agreement. Follw-up discussion on this topic is in the mailing-list under 
the thread "WSRF and GRAAP".

While the group welcomes and will look at proposals for alternate designs making use of other specification, the 
specification has been written so far using WSRF concepts such as resource properties, and thus the 
EndpointReferenceType from WS-Addressing (for instance to uniquely identify Agreement service-resource pairs). 

We need to decide if we go ahead and keep the spec dependent on WSRF so as to use it for proposing WSDL etc...or if we 
should make the specification  purely textual with an abstraction of concepts such as resource properties, 
endpoint references, etc...

Pasted below is the original email from Jon McLaren:
_____________________

All,

During the third meeting of the GRAAP-WG at GGF10 in Berlin, I voiced
concern over the adoption of WSRF in WS-Agreement.

From the discussion, this doesn't seem to be decided.  However, in one of
the slides, the phrase "resource properties" came up.  It seems that the
specification may be drifting towards WSRF.

However, this shouldn't be something that the group enters into lightly, or
without discussion.  If WS-Agreement becomes WSRF-specific, then anyone
using it becomes tied to WSRF too.  So, when the GRAAP group makes terms for
WS-Agreement-based advance reservation (AR is the original purpose of the
group), this "protocol" will only be available in a WSRF setting.

There is also an impact on other groups, which might want to have to use
WS-Agreement.  It's probably not such an issue for OGSA, which I'm told will
likely adopt WSRF - but what about JSDL?  Are there other groups?

Perhaps it was OK to be OGSI-specific when it was "the only game in town".
However, I don't really see any consensus that WSRF is the only way forward.
I certainly didn't get this picture when attending various groups in
Berlin...

Discuss!

Jon.

.