Fwd: The CPA composition tool

[Martin Sachs <msachs@cyclonecommerce.com>]

Here are some comments and questions from Sacha Schlegel.  Please review 
and reply to all since Sacha is not on the team roster.

Regards,
Marty

>Subject: The CPA composition tool
>From: Sacha Schlegel <schlegel@cs.curtin.edu.au>
>To: Martin Sachs <msachs@cyclonecommerce.com>
>Cc: Tim McGrath <tmcgrath@portcomm.com.au>
>X-Mailer: Ximian Evolution 1.4.5
>Date: Tue, 14 Oct 2003 17:08:36 +0800
>X-XWall-Bayes: 19
>X-OriginalArrivalTime: 14 Oct 2003 09:08:36.0315 (UTC) 
>FILETIME=[BFF6D2B0:01C39232]
>
>Hi Mr Sachs
>
>Hope you are having time to comment on two things I am working on.
>
>1st issue:
>----------
>
>Going over the specifications (CPPA spec, Appendix E - CPA composition),
>once again, I still have lots of those "aha's" experiences.
>
>I really see an advantige of being part of a project from the early
>beginning, where reasons for certain decision can be followed more
>easily.
>
>What currently makes me think is the following:
>
>The BusinessTransactionCharacteristic attributes are quite important.
>The BusinessTransactionCharacteristic element, among one or more (which
>makes me even more thinking) ChannelId element, is a child element of
>ThisPartyActionBinding. The CanSend (or CanReceive) element holds the
>ThisPartyActionBinding.
>
>The BusinessTransactionCharacteristice attributes dictate (maybe wrong
>word) that some elements down the XML tree, in particular the Packaging,
>DocExchange and Transport way, have to be present or not.
>
>Theoretically, two CanSend elements, with different
>BusinessTransactionCharacteristic attributes (eg once with "transient"
>isConfidentiality, once with "none" isConfidentiality), can use the same
>delivery channel, thus the same transport element. The transport element
>must have a TransportSecurityProtocol to enalbe "transient"
>confidentiality.
>
>So looking soely at the CanSend element with the "none"
>isConfidentiality attribute in its BusinessTransactionCharacteristics
>element I find a TransportSecurityProtocol element which is NOT
>necessary for this particular CanSend element.
>
>Not sure if the advantage of using the IDREF XML data type for
>DeliveryChannel, Packaging, DocExchange and Transport overweights the
>disadvantages.
>
>The way how a CPP is constructed starts to get interesting, but for an
>application receiving a CPP or a CPA should not trust the document and
>must validate the document. Validation here does not only to check if it
>is a valid XML document but also that it is logically a valid CPA or
>CPP.
>
>Summary: A real CPP or CPA validation is necessary; The XML schema is
>not enough.
>
>Having quickly looked at Schematron, that might be a variant to validate
>CPP's and CPA's. It would be great to have those rules (eg if the
>document is a CPA each CanSend, CanReceive element must have one
>OtherPartyActionBinding element) in a descriptive way and having those
>rules be part of the CPPA spec.
>
>On a sidenote: I havent looked closer at the MessageCharacteristics
>element but I guess it holds similar issues.
>
>2nd issue:
>----------
>
>Are the "Negotiation Requirements" and "Collaboration Protocol Agreement
>Simple Negotiation Business Process Model" still maintained documents of
>the CPPA Negotiation team?
>
>
>Kind regards
>
>Sacha Schlegel
>--
>------------------------------------------------
>Sacha                                   Schlegel
>------------------------------------------------
>4 Warwick Str, 6102 St. James, Perth,  Australia
>sacha@schlegel.li                www.schlegel.li
>public key:            www.schlegel.li/sacha.gpg
>------------------------------------------------

*************************************
Martin Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQA/i70UjTNlL0xFfy4RAgsoAKC0iu4qSxssq+FUmrDt9S5PMe9xNQCgkfZs
eDKP6CJetGrLnFSGxmhwCVg=
=XhcP
-----END PGP SIGNATURE-----