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 <>
From: Martin Sachs <>
Subject: Re: The CPA composition tool
Cc: Tim McGrath <>, ebxml-cppa
<>
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
www.schlegel.li
public
key:
www.schlegel.li/sacha.gpg
------------------------------------------------
*************************************
Martin Sachs
standards architect
Cyclone Commerce
*************************************
Martin Sachs
standards architect
Cyclone Commerce
