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

[Martin W Sachs <mwsachs@us.ibm.com>]

Jean,

Please look again at Ver. 1.0. I don't know what you mean by "However, in
1.1 we've agreed not to make
PartyRef machine processable". We specifically added the type element to
Ver. 1.0 so PartyRef would be machine processable.  That was specifically
in response to an issue raised at the start of the Vienna meeting. There is
no value to embedding any party reference information in the CPA since it
is already in the document pointed to by PartyRef.

If this must be discussed on a conference call, please leave it until next
week as I will be unable to attend this week.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Jean Zheng <Jzheng@vitria.com> on 10/23/2001 08:19:13 PM

To:    "'Dale Moberg'" <dmoberg@cyclonecommerce.com>
cc:    ebxml-cppa@lists.oasis-open.org
Subject:    RE: [ebxml-cppa] Proposed schema changes, plus illustrative
       examp      le



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>
>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>