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

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>

* 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>

* 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>

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>


In terms of who developes what, I think its a political process and all 
we can do is to facilitate a number of relevant possibilities.
<DB>Sad ... but very true!</DB>

-----Original Message-----
From: Anders W. Tell [mailto:opensource@toolsmiths.se]
Sent: Thursday, June 05, 2003 8:10 AM
To: Burdett, David
Cc: 'Assaf Arkin'; Ricky Ho; Yaron Y. Goland; public-ws-chor@w3.org
Subject: Re: Combining Policies (was RE: Partial executability/
determinis m of a Chor description language


David,

see comment inline.

Burdett, David wrote:

>Anders
>
>Having taken a quick look at the document you attached, it seems to me that
>really it describes a legal framework that identifies how businesses would
>interact. It does not necessarily specify the detail of how they would
>interact.
>
Yes, the "top" are general provisions which sometime may be difficult or 
impossible to correctly represent in electronic form other than as text. 
The UBAC work were doing covers simple textual agrement to complext 
eContracts. This with an approach that we start simple with textual 
clauses and work our way toward semantically rich,executable and 
computer interpretable agreement components.

>I am also wondering what your thoughts are about separating agreements into
>three levels:
>1. Technology agreements that cover messaging, technical protocols,
>security, etc
>
Seems resonable , these are often call technical addendums.

>2. Process and data agreements that cover the choreography and data to be
>used, and
>
Seems resonable.

>3. Business agreements that specify how individual parties will interact.
>
Seems resonable of you by interact include that parties are obligated to 
..., have the right to...., is prohibited from....

>I think that technology agreements could be developed that could be used by
>multiple industries, and process and data agreements could be developed for
>individual industries and that the Business agreements could link the two
>together for use in a particular instance.
>  
>
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.

* 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.

* An Agreement contains agreement components and is signed by parties 
that obligate themself to the semantics specified by the agreement 
components.

I believe that desctinctions like these are important othewise 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.

In terms of who developes what, I think its a political process and all 
we can do is to facilitate a number of relevant possibilities.

/anders