[graap-wg] condition expression language requirements for WS-Agreement

[Karl Czajkowski]

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 at univa.com