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

[Tony Weida <rweida@hotmail.com>]

As an aside concerning the URI referenced by PartyRef's type attribute, I
captured the following note for Issue 151 at the Palo Alto F2F:
"Non-normative statement suggesting XML schema.  Jean to research possible
examples."

Tony
----- Original Message -----
From: "Martin W Sachs" <mwsachs@us.ibm.com>
To: "Jean Zheng" <Jzheng@vitria.com>
Cc: "'Dale Moberg'" <dmoberg@cyclonecommerce.com>;
<ebxml-cppa@lists.oasis-open.org>
Sent: Wednesday, October 24, 2001 12:23 AM
Subject: RE: [ebxml-cppa] Proposed schema changes, plus illustrative examp
le


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