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

[Tony Weida <rweida@hotmail.com>]

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>