Karl, Thank you very much for pointing out the RangeValue_Type in the Job Submission Description Language (JSDL), which I had overlooked in my earlier reading of WS-Agreement. This is exactly the type of mechanism on which automated intersection/agreement can be based. RangeValue_Type handles numeric types; also needed, however, are SetValue_Type types for IP address subnets, regular expressions over strings, and a few other basic types used in service agreements, along with Boolean operators for combining range or exact-value constraints. The simple condition language in the WS-Agreement "Preference Example" is an example of such Boolean operators. So many of the pieces exist. If they can be pulled together into a "condition expression language" that could be referenced, it would go far toward allowing automated agreement, and would improve interoperability. The variables used in such expressions will be domain-dependent, but if the condition expressions over their values use a standard condition expression language, then implementations of WS-Agreement can be smaller (supporting fewer mechanisms), more easily testable (no domain-specific tests of comdition expression intersection/agreement), and more interoperable. Agreements can be more easily computed by brokers or other 3rd parties that may not have or need the domain-specific code associated with the variables themselves: this seems like an important consideration for Grid environments. Interoperability may not be a goal, but if an implementation of WS-Agreement will be used with more than one other partner, with more than one other condition expression language, being able to reduce the number of mechanisms that need to be supported is at least a valuable objective. For the current draft, if you are really intending to address the condition expression language in a meaningful way in the next version, how about removing the suggestions that XQuery might be an appropriate condition expression language. XQuery is great for what it was designed to do: express query constraints. But it was not designed for nor is it suitable for expressing agreement constraints. There are no intersection/agreement mechanisms defined for XQuery expressions in general, and intersection/agreement is undefinable in many cases. This would involve removing the statement that "An example of a generic assertion language can be found in [XQUERYX]." in section "4.2.6.2 Qualifying Condition and Service Level Objective" and the statement that "A general purpose constraint language has been proposed as part of the XQuery and XPATH language. The XML rendering of this expression language, XQueryX, MAY contain a suitable constraint language that can be used to phrase constraints involving multiple items." in section "5.1.2 Free–form Constraints", along with the subsequent "wsag:XQueryXConstraint" extension of "<wsag:Constraint/>". Please understand, I am not objecting to XQuery itself, but only to suggestions that it may be an appropriate constraint language where agreement semantics are needed. Few WS-Agreement users will understand the real implications of the choice of condition expression language until they have invested significant time and effort into implementation and use. At least don't lead them down the wrong path while you wait for an appropriate path to appear. Regards, Anne Karl Czajkowski wrote On 02/08/06 10:06,:

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

-- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692

I'll add Anne's suggestion to the 'Public Comments' list Toshi. Karl Czajkowski wrote:

On Feb 08, Anne Anderson modulated: ...

...

This would involve removing the statement that "An example of a generic assertion language can be found in [XQUERYX]." in section "4.2.6.2 Qualifying Condition and Service Level Objective" and the statement that "A general purpose constraint language has been proposed as part of the XQuery and XPATH language. The XML rendering of this expression language, XQueryX, MAY contain a suitable constraint language that can be used to phrase constraints involving multiple items." in section "5.1.2 Free–form Constraints", along with the subsequent "wsag:XQueryXConstraint" extension of "<wsag:Constraint/>".

Please understand, I am not objecting to XQuery itself, but only to suggestions that it may be an appropriate constraint language where agreement semantics are needed. Few WS-Agreement users will understand the real implications of the choice of condition expression language until they have invested significant time and effort into implementation and use. At least don't lead them down the wrong path while you wait for an appropriate path to appear.

Regards, Anne

I would strongly endorse such a change, as well as a replacement text that mentions a better assertion language. I think this is one of those spots where something was stuffed in because previous commentary had called for more concrete examples...

While we're at it, we SHOULD remove the inappropriate use of "MAY" in such a recommendation. :-)

karl