RE: [ebxml-cppa] Proposed schema changes, plus illustrative examp le

[Jean Zheng <Jzheng@vitria.com>]

1. 	<element name="Service" type="tns:service.type"/>

During our f2f meeting, I had the impression that there will be an
additional attribute (xlink?) for the "Service" element.  Has that changed?

2. 	<element name="PartyInfo">
		<complexType>
			<sequence>
				<element ref="tns:PartyId"
maxOccurs="unbounded"/>
				<element ref="tns:PartyRef"/>
				<element ref="tns:CollaborationRole"
maxOccurs="unbounded"/>
				<element ref="tns:Certificate"
maxOccurs="unbounded"/>
				<element ref="tns:DeliveryChannel"
maxOccurs="unbounded"/>
				<element ref="tns:Transport"
maxOccurs="unbounded"/>
				<element ref="tns:DocExchange"
maxOccurs="unbounded"/>
			</sequence>
		</complexType>
	</element>

Can we also have a "PartyName" element under "PartyInfo"?  It could be very
useful in the real world.  For example, for an application that's configured
by a CPA, when an exception occurred, the application can send an exception
that contains at least a human readable name for the Party that is involved.
I understand that it is not necessary from a pure technical point of view,
but to generate a report for humans, a name is usually more useful than an
id.  Does anyone strongly object to this?

Thanks,
Jean

> -----Original Message-----
> From: Arvola Chan [mailto:arvola@tibco.com]
> Sent: Monday, October 22, 2001 4:46 PM
> To: ebxml-cppa@lists.oasis-open.org
> Subject: [ebxml-cppa] Proposed schema changes, plus 
> illustrative example
> 
> 
> I like to propose a strawman set of changes to the CPP/A 
> schema to address
> the following issues:
>   1.. Clarify the purposes of various certificate references
>   2.. Allow both server and client certificates to be specified for
> transport level security
>   3.. Allow a default delivery channel to be used for 
> multiple actions with
> different Packaging
>   4.. Allow multiple override elements for the same action
>   5.. Allow a SimplePart to be reused
>   6.. Allow multiple types of response to be returned on a synchronous
> delivery channel
> More specifically, please take a look at the attached XSD file for the
> following proposed changes:
>   a.. Clarify purpose of CertificateRef under CollaborationRole. See
> 
>   CollaborationRole.DefaultSigningCertificate
> 
>   b.. Add client certificate for transport security and 
> distinguish between
> client and server certificates. See
> 
>   Transport.TransportSecurity.ServerCertificateRef
>   Transport.TransportSecurity.ClientCertificateRef
> 
>   c.. Clarify purpose of CertificateRef in NonRepudiation element. Add
> signing CertificateRef for receiver in case the DocExchange is used in
> conjunction with a synchronous delivery channel. See
> 
>   DocExchange.ebXMLBinding.NonRepudiation.initiatorCertificateRef
>   DocExchange.ebXMLBinding.NonRepudiation.responderCertificateRef
> 
>   d.. Make SimplePart a top-level element to allow for reusability.
> 
>   e.. Allow ServiceBinding to specify different Packaging for 
> different
> actions. (It is not sufficient to provide a single Packaging for one
> ServiceBinding because multiple actions with different 
> schemas may not be
> able to share the same Packaging.) Default delivery channel can be
> synchronous or asynchronous. If synchronous, packaging for 
> request message
> and packaging for response must both be specified. See
> 
>   ServiceBinding.ActionBinding
> 
>   f.. Allow action level override within ServiceBinding to specify
> (synchronous or asynchronous) channels along with Packaging. 
> If channel is
> synchronous, can specify packaging for the response. Remove uniqueness
> constraint on action name to allow both synchronous and asynchronous
> channels to be used for the same action, for example. See
> 
>   ServiceBinding.OverriddenActionBinding
> 
>   g.. Allow for more than one response packaging for a 
> synchronous delivery
> channel because an exception can be returned in lieu of a 
> response. See
> 
>   Packaging.CompositeList (maxOccurs="unbounded")
> The attached sample CPA is intended to illustrate:
>   a.. BPSS instance for a RosettaNet PIP (see attached 3A4.xml).
>   b.. CPA for a BPSS business process that corresponds to a 
> RosettaNet PIP.
>   c.. Synchronous and asynchronous delivery channels.
>   d.. Packaging used with synchronous and asynchronous 
> delivery channels.
>   e.. Packaging for stand-alone business signals and exceptions.
>   f.. Reuse of SimplePart for message header.
> If you want to examine the example using an XML Schema aware 
> editor, please
> be aware that xsi:schemaLocation is currently set to be
> c:\ebxml\draft-cpp-cpa-02.xsd. The sample BPSS instance 
> cannot be read using
> an XML Schema aware editor because the corresponding BPSS 
> schema is not
> provided.
> 
> Looking forward to your comments,
> -Arvola
> 
>