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

[Tony Weida <rweida@hotmail.com>]

Marty,

The detailed description of issue 151 follows.  I expect it to evolve
following teleconference discussion.

Tony


However, [PartyRef} doesn't seem to specify the exact definition for the
"type"
of url (e.g. is it a web page? an ebXML registry, a UDDI, or LDAP), nor does
it
specify the correct structure of the information that is stored at the
particular location.

Without the above information, it does not seem possible to "automatically"
populate the related Party information during importing/exporting a CPP.

Reply from Marty Sachs: Section [7.5.2.3] defines the type attribute.  We
probably should add a
non-normative suggestion that the type information be in the form of an XML
Schema document or DTD.  It does say that if the type attribute is omitted,
the information MUST be an HTML web page.


----- Original Message -----
From: "Martin W Sachs" <mwsachs@us.ibm.com>
To: "Tony Weida" <rweida@hotmail.com>
Cc: <ebxml-cppa@lists.oasis-open.org>
Sent: Wednesday, October 24, 2001 12:18 AM
Subject: Re: [ebxml-cppa] Proposed schema changes, plus illustrative examp
le


>
> Tony,
>
> PartyRef already has a type element in Ver. 1.0.
>
> Either issue 151 is left over from before Vienna or it means something
> else.  Please check and clarify.
>
> 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
>
****************************************************************************
*********
>
>
>
> Tony Weida <rweida@hotmail.com> on 10/23/2001 03:02:49 PM
>
> To:    ebxml-cppa@lists.oasis-open.org
> cc:
> Subject:    Re: [ebxml-cppa] Proposed schema changes, plus illustrative
>        examp      le
>
>
>
> Regarding PartyRef and PartyName, the closest we have to an existing issue
> is 151: Specify type for PartyRef.  Since discussion is planned for this
> week's teleconference, I plan to frame an issue according to the outcome
of
> that discussion.
>
> Tony Weida
>
> ----- Original Message -----
> From: "Dale Moberg" <dmoberg@cyclonecommerce.com>
> To: "Jean Zheng" <Jzheng@vitria.com>; "Arvola Chan" <arvola@tibco.com>;
> <ebxml-cppa@lists.oasis-open.org>
> Sent: Tuesday, October 23, 2001 2:37 PM
> 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>
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>