Re: Combining Policies (was RE: Partial executability/ determinis m of a Chor description language

Burdett, David wrote:

>Anders said ...
>
>IMHO the leveling approach is often appeling but when used in the 
>context of agreeements, real life more complex than that.  I like to 
>think in terms of topology or formation. I also like to separate 
>agreements from specifications.
><DB>I agree that life *can* be more complex than that. However the problem
>with complexity is that it makes successful interoperability to achieve. I
>therefore think it should be a goal to have a limited number of options that
>a "leveled" approach would facilitate.</DB>
>
<awt> Reducing complexity as much as possible is a key goal  for all of 
us. Selecting/prioritizes a  number of AgreementTypes is certainly 
important.
</awt>

>* A specification is a collection specification components that one or 
>more authors have created (possibly with copyright)  The authors sign 
>the specification with an "Authenticity of Origin" signature. Which 
>means the authors does not obligate themself to use the spec and is not 
>responsible for usage by others.
><DB>I like this idea, but the specification is not the implementation. Do
>you also need a signature or certification that some software follows the
>specification. However doing this might result in some liability issues
>perhaps.</DB>
>
<awt>
Yes, usage is tricky, what does a signed AgreementReference mean, what 
is the Intention behind it?
A loosely coupled certification process is probably better.
</awt>

>* An Agreement contains agreement components and is signed by parties 
>that obligate themself to the semantics specified by the agreement 
>components.
><DB>I agree, but the fewer the agreement components the better for ease of
>implementation and interoperability. This probably means that each agreement
>has to be larger in scope.</DB>
>
<awt>
Yes, Creating AgreementComponents in resonable sized chunks is very 
important.
</awt>

>I believe that desctinctions like these are important otherwise we never 
>know what the signature means. Reuse almost always involve 
>specifications, even on an industry level.
>
>So the an agreement topology is the art of relating agreements, 
>specification and parts thereof, ie. references, appendix, include, 
>govern, govern with superiority etc.
>
>Here I also see benefits from using the notion of Specifciations as 
>containers of components which may or may not be related.  WSDL is 
>component, Chorograpghy is a components, W3C XML Schema is a component. 
>A Choreography is bound (static, dynamically) to a syntax specific 
>InformationSpecification such as XML Schema.
><DB>As well as an agreement specifying the specifications that are being
>followed, should it also specify the bits of the specification that are NOT
>being followed. So really the aggreement is a combination of aggregation and
>restriction. I think that restriction is sometimes really necessary, as WS-I
>has demonstrated, in order to get interoperability. You might also find that
>two specifications actually conflict in some way and therefore you need to
>say which of the two you are actually following.</DB>
>
<awt>
 Yes, deontics is useful, permissions, prohibitations as well as 
obligations.

In UBAC we have also on the agenda to discuss constraints to be used 
when constructing an agreement. These constraints are discarded after 
the agreement has been constructed (first step in its lifecycle), i.e. 
CatalogConstraints that are an expression of the the Catalog maintainers 
(industry org,...) Intent. Of course catalog composer can break these 
constraints without liability.
</awt>



/anders

Received on Sunday, 8 June 2003 13:19:20 UTC