Re: [ebxml-cppa] Fwd: The CPA composition tool

[Himagiri.Mukkamala@sybase.com]

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

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


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

</Hima>

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

signature9.asc