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

[Jean Zheng <Jzheng@vitria.com>]

Dale,
I agree that PartyName should be part of contact information
for a party.  However, in 1.1 we've agreed not to make
PartyRef machine processable, so having a PartyName element 
in addition to PartyRef might help.

Can we make PartyName a mandatory element? From the 
application point of view, the value of PartyRef
is not always clear, for 1.1.

We can discuss this on the call.

Jean

> -----Original Message-----
> From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
> Sent: Tuesday, October 23, 2001 11:38 AM
> To: Jean Zheng; Arvola Chan; ebxml-cppa@lists.oasis-open.org
> Subject: RE: [ebxml-cppa] Proposed schema changes, plus illustrative
> examp le
> 
> 
> Comments in-line.
> 
> 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?
> 
> 
> I believe that we intend to align with BPSS on this one.
> Brian Hayes will update us on what to point to in order
> that we can get the service value from the BPSS. So I
> do not think our intention has changed to have an xlink
> URI be able to point to the correct value. Raise this
> at the meeting this week if I forget!
> 
> 
> 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"? 
> 
> <Dale>
> 
> We can do whatever we all agree to! 
> 
> We can revisit why we offloaded
> (to PartyRef)
> a lot of that detail earlier
> (for version 1.0) and we can 
> re-raise the issue. We did a repair
> in this area for 1.1 when we added
> an optional type attribute which
> was to serve as a way to "support"
> more structured approaches to
> name information by providing
> a governing schema. Your use
> case sound like a contact info
> name for emergencies, and we
> probably need a discussion and
> then a vote. 
> 
> 
> I will try to get this one on the agenda
> for more discussion this week,
> and possible vote by the November voting
> meeting. 
> 
> If we do not have this
> as a 1.1 issue (I need to check) 
> we can get it added by Tony.
> 
> Also, we might use
> either a PartyRef or a PartyName or a sequence
> of choice over at least one of them. 
> That would probably be 
> a more conservative change for 1.1. 
> 
> Would something like this sequence-over-choice
> suffice? Or do you want PartyName as a mandatory
> element to be added in addition to PartyRef?
> 
> </Dale>
> 
>  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
> > 
> > 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>