On Feb 08, Anne Anderson modulated:
WS-Agreement is supposed to be "a Web Services protocol for establishing agreement between two parties". Unless there are defined mechanisms for reaching agreement on the contents of a WS-Agreement specification, I don't believe WS-Agreement has met its primary goal.
I think I understand your point, and unfortunately this is an area that has not been documented very well. Aside from your assertion below, I think most of us have considered this a non-normative documentation issue that should be captured in a "primer" document. In a nutshell, the expected "agreement handshake" really starts with the initiator consuming the advertised template(s) from a responder. The first decision then is the initiator deciding whether the responder accepts an agreement format that is acceptable to the initiator. If so, he may proceed with formulating an agreement and making an offer. If not, he has to go back to discovery. The second decision is whether the responder understands an offer and wants to accept it. This of course requires being able to extract the semantic content of the offer in some form such that the responder's policies can be evaluated to determine whether to accept or reject.
Particularly in the area of condition expression languages, there has been little successful work on feasible intersection/agreement mechanisms other than the work done in the field of "narrowing algorithms". For example, there is intersection/agreement between two general XQuery expressions is undefined. There is a comment suggesting that the condition expression language/dialect be completely at the discretion of the WS-Agreement instance originator, which will make this problem even harder unless there is a corresponding requirement that two parties must either agree on the dialect used (and that it have a feasible intersection/agreement mechanism) or that there must be a defined intersection/agreement mechanism between the two dialects.
You are assuming, perhaps, that a general WS-Agreement implementation will exist that computes intersections without domain-specific knowledge. While I think this would be interesting, I think many participants have set a lesser goal of being able to implement domain-specific WS-Agreement implementations which can interoperate according to a "profile" specification. There are two reasons this is worth pointing out: 1) the profile may define the specific intersection model that is appropriate for the domain 2) the profile may define additional discovery content to simplify discovery of "interoperable profile implementations" You might be pleased if you were to look into the JSDL job example in the specification. I think you will find that the "range value" type in the JSDL language has very simple intersection semantics which can allow narrowing between the template, offer, and responder operating policies to determine a match.
I recommend inserting a requirement that any language/dialect specified for WS-Agreement condition expressions must have a referenceable specification for computing intersection or agreement between any two expressions in the language/dialect. Unless this is done, WS-Agreement will not meet its goals and will not be interoperable.
I don't have a problem with inserting a "SHOULD" statement about this, but I think I disagree about the consequence of not having it. I do not think there is a necessary interoperability between all WS-Agreement implementations, but merely between implementations which follow profiles where the conditional languages are normatively defined. I would be interested to hear others' opinions on this... karl -- Karl Czajkowski karlcz@univa.com