RE: [ebxml-cppa-negot] Future document

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

>
> 1.3 I thought that once you agree on an element you cannot change your
> mind again might be a problem. Especially in case of interdependencies

> (use case necessary in the way of if both parties do not talk about a 
> SecureTransport they cannot change the 
> BusinessTransactionCharacteristics 
> (isConfidentail,isAuthenticated,isTamperProof or 
> isNonRepduationRequired) attribute which asks for a SecureTransport 
> element). On the other hand this could be good as one party then is 
> assured, that once value is set it is set. Otherwise you might end up 
> in a loop, like in a game where both players repeat the same move 
> again and again because they think thats the only way to go.
>
> Might be difficult to provide a fair list which elements you allow to
> renegotiate.
>
> MWS: You are exactly right.  That's why we now say "no going back".  I
> will add your comments to the futures document.

mm1: This brings up the point if they negotiate items that are in 
conflict with the assumptions in the BPSS instance document (for 
example, message level assumptions that may conflict with the business 
level definitions). I understand that CPP/A can override BPSS defined 
parameters, but what of the business agreement.

Dale> The CPPA permits BPSS BusinessTransactionCharacteristics to have
different values than those found in a given BPSS instance. Security
values, for example, may be strengthened over what was present in the
referenced BPSS instance because of a greater disutility for, say, loss
of data confidentiality in special business situations. A BPSS instance
after all may only reflect the expected average characteristics needed
for a BP. 

Also, the values could be weakened. This is usually what people worry
about. However, this result could reflect an assessment that loss of
data confidentiality is, for certain collaborations, no big deal, and
just not worth the computational and management expense of encryption.

However, when using Negotiation, the party proposing the CPA can always
create a NDD that does not allow changes to the
BusinessProcessCharacteristic values. Enforcing the BPSS instance
specified values is possible. 

CPPA permits modifications to design details at configuration time.
Runtime follows design _as_ configured.

I guess I need a little more information to comment on the question
"what of the business agreement". CPPA does not configure values of
business "terms and conditions," all those little dotted i's and crossed
t's pertaining to remedies and penalties when things go wrong in various
ways or for the standing business rules (20% discount on full container
orders) etc. While the general technology of Negotiation under a NDD
could be used to edit any XML based representation of an agreement, the
TC hasn't indicated any real interest in incorporating business level
aspects (beyond what we now touch on) into the CPPA.

What other BPSS expressed things are you concerned with? The documents
used in a specific process? We have not really provided anything in the
CPPA for doing that, except possibly in the NamespacesSupported
elements. It could be that the WSDL extensions coming up in CPPA.next
could override. Or we could add a new extension for document overrides.
I guess I would need to know the specific aspect of the agreement that
is of interest.

But I think using Xpaths to identify what can be changed, and the
various enumerations and ranges declaring how those changes can be made,
is a fairly general and flexible approach. It could certainly be applied
to collaborations involving exchanging XML documents with the goal of
finding an XML instance version acceptable to all sides.





 Is this a potential work 
item for ebBP or between ebBP and CPPA (team and negotiation team)? 
Maybe I am misinterpreting?