|
Peter:
I agree with you on point #1.
I will use draft-cpp-cpa-08b.xsd as the starting point for my
wildcard related schema changes.
I am applying my changes using the 1.03 version Tony has sent
me. I expect to send you my updated version by the end of tomorrow.
Regards,
-Arvola
Arvola:
1.
Regarding your point 1 below, are you in favor of doing this now? To me, when
we start specializing things into CPP and CPA flavors, we might as well ask
whether we should just have different schemas for each. And *that* seems like
more than we should bite off for 1.1. My opinion is that we should stick with
your original suggestion of documenting that the OPBA will be used only in the
CPA and call it good for now.
2.
Regarding your point 2, more sloppiness on my part (sigh). The fixed
version (08b) is attached.
3.
Regarding your point 3, I updated the examples accordingly (attached). I wish
there was some straightforward way to allow parties to reference/include
predefined SimplePart and Packaging elements located external to the CPPs,
because requiring parties to define these things properly, on their own, seems
like a usability problem. The XInclude specification looks promising, but
it's not a Recommendation yet.
4. I will be submitting text changes for the spec corresponding to
the *CertificateRef, SecurityDetails, *SecurityDetailsRef, *Sender* and
*Receiver* changes to the schema. I hope I can get this done by Friday.
Peter
Peter:
Some comments:
- Re: point 2 in your previous message (see attached): I can
think of no simple way to require that OtherActionBinding be mandatory in
the case of CPAs and not present in the case of CPPs. One round-about
approach is to specialize PartyInfo into CPPPartyInfo and CPAPartyInfo,
CollaborationRole into CPPCollaborationRole and CPACollaborationRole,
ServiceBinding into CPPServiceBinding and CPACollaborationBinding,
WillInitiate into CPPWillinitiate and CPAWillInitiate, WillRespond into
CPPWillRespond and CPAWillRespond, etc. For CPPWillInitiate and
CPPWillRespond, there will only be one sub-element: ThisPartyActionBinding;
for CPAWillInitiate and CPAWillRespond, there will be two sub-elements:
ThisPartyActionBinding and OtherPartyActionBinding. Thus, CPP will have
CPPPartyInfo as sub-elements and CPA will have CPAPartyInfo as
sub-elements.
- Re: point 2 in your enclosed message: This change does not
seem to have been included in draft-cpp-cpa-08a.xsd. I still see
AckSecurityDetailsRef and AckCertificateRef in
draft-cpp-cpa-08a.xsd.
- Re: recommendation on the prefixing of ID fields with
trading partner names. To be more realistic, the SimplePart and Packaging
IDs in the two example CPPs and the example CPA should be prefixed with the
trading partner names. In the CPA, the SimplePart and Packaging elements
should essentially be the union of the SimplePart and Packaging elements
from the two CPAs that are effectively being merged.
- Will you be submitting all the necessary textual changes to
Version 1.01 of the CPA spec to reflect the schema changes in
draft-cpp-cpa-08a.xsd, for incorporation into Version 1.03?
Regards,
-Arvola
Attached is an
updated version of the CPPA schema and examples.
This version
(08a) differs from the previous version as follows:
1. Fixed a
validation problem caused by the empty <SecurityPolicy/>
elements in the
examples.
2. Added
OtherPartyActionBinding elements to the CPA
example.
3. Removed the
AckSecurityDetailsRef from SenderNonRepudiation
and
AckCertificateRef from ReceiverNonRepudiation.
4.
Added ActionContext elements to the request/response
ActionBindings in the
examples.
Regards,
Peter
|