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: Re: The CPA composition tool



Sacha makes some interesting points in his message. In addition to his specific points, this one:
"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."
is something the team might want to give more thought to for the version 3 time frame.  We have certainly tried to state semantic rules (those that XML Schema can't enforce) but have we gone far enough to enable semantic validators to be constructed? Another interesting possibility for the future might be to collect all the semantic rules in one chapter and perhaps express them in a language that can be easily interpreted by a machine.

Regards,
Marty

Date: Tue, 14 Oct 2003 15:55:07 -0400
To: Sacha Schlegel <schlegel@cs.curtin.edu.au>
From: Martin Sachs <msachs@cyclonecommerce.com>
Subject: Re: The CPA composition tool
Cc: Tim McGrath <tmcgrath@portcomm.com.au>, ebxml-cppa <ebxml-cppa@lists.oasis-open.org>

Hi, Sacha

Thank you very much for your comments.  My responses are embedded below (MWS:).

Regards,
Marty

At 05:08 PM 10/14/2003 +0800, Sacha Schlegel wrote:
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.

MWS: The example you give here is not a particular problem.  Because one of the CanSend elements requires transient confidentality and the other requires no confidentially, a run-time system would configure the transport security implementation into the delivery channel implementation.  The run-time would ensure that transport security is "turned on" for those transactions that require it and turned off for those that require "none". I do not believe that the CPPA team has actually discussed the problem you raise, so I hope that this is the correct answer.  I also hope that someone else who sees your message and my response will respond and especially tell us what existing run-time systems would actually do.

MWS:  I will be much more concerned if you come up with an example where the combination of characteristics is such that the two CanSends cannot share a delivery channel definition.  However even this is not a real problem since two diffferent delivery channels does not mean two separate delivery channel implementations.  It does mean that the run-tiem design has to be very flexible.


Not sure if the advantage of using the IDREF XML data type for
DeliveryChannel, Packaging, DocExchange and Transport overweights the
disadvantages.


MWS: If the main disadvantage of IDREF is the one you describe above,  this does not say that IDREFs cause major problems.  It does mean, as you say below, that "real" CPP or CPA validation is necessary. I would think it a natural extension of a CPA or CPP composition tool to be able to take an existing CPP or CPA and perform a "semantic" validation.


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.


MWS:  As I said above, this is very true.  I hope that tool implementers do have semantic validators.


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.


MWS:   Some rules of this kindare stated in the text of the CPPA specification.  If you notice places where more rules should be stated, please let us know.


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

*************************************
Martin Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com



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