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: Re: [ebxml-cppa] Fwd: The CPA composition tool

<Hima> comments inline

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

<Hima> Business TransactionCharacteristics element is meant to override the behavior
defined by the BPSS from which the CPP/A may be derived. Implementors could choose
to go either way and I don't think the specification normatively prescribes in a
particular direction for the scenario that you mentioned. I agree with you in that
by normal XML validation, CPP/A cannot be deemed to be complete. To comply with the specification,
semantic validation must be done based on the the presence or absence of elements or attributes,
an example of which you mentioned.

>2nd issue:
>Are the "Negotiation Requirements" and "Collaboration Protocol Agreement
>Simple Negotiation Business Process Model" still maintained documents of
>the CPPA Negotiation team?

<Hima> I think so, will let Marty confirm that

>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 To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa/members/leave_workgroup.php.


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