OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Fwd: The CPA composition tool

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


>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) 
>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
>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
>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"
>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
>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
>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
Version: GnuPG v1.2.3 (GNU/Linux)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]