Dan,
Actually, I understand that IBM actually owns a large number of DUNS
numbers for different parts of the enterprise. They are all "IBM" (unless
some are "Lotus", "Tivoli", etc.).
Naming an MSH is a whole other ball of wax. An MSH is not a pile of
circuits nor some number of lines of code. An MSH is really a data
structure that supports some part of the enterprise that is behind it. The
same circuits and lines of code might implement many MSHs. It isn't obvious
to me that any of the identifiers, endpoint addresses, or names that we
have been discussing is appropriate for labelling a single MSH. A single
PartyId might be served by many MSHs, so PartyId doesn't sound like the
right answer. In other cases, a single MSH might serve multiple PartyIds.
The MSG team would have to define what constitutes an MSH. Before defining
what constitutes an MSH, the MSG team would have to decide what purpose is
served by identifying an MSH since that may determine the nature of the
identifier.
One possibility (jumping over the requirements discussion that should
preced this statement) is that an MSH is identified by the concatenation of
the PartyId and CPAId.
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
*************************************************************************************
Dan Weinreb <dlw@exceloncorp.com> on 10/25/2001 01:45:10 PM
Please respond to "Dan Weinreb" <dlw@exceloncorp.com>
To: Jzheng@vitria.com
cc: Martin W Sachs/Watson/IBM@IBMUS, dmoberg@cyclonecommerce.com,
ebxml-cppa@lists.oasis-open.org
Subject: Re: [ebxml-cppa] Proposed schema changes, plus illustrative
examp le
Date: Thu, 25 Oct 2001 10:04:22 -0700
From: Jean Zheng <Jzheng@vitria.com>
Actually, in a case like this, don't you really want to know which MSH
the exceptions were from? Marty has explained to me that a PartyId
doesn't actually identity an MSH; there might be 10,000 MSH's within
the IBM corporation, but there might be just be one PartyId, for
"IBM". For the purposes you're discussing here, I would think that
what's needed is a way to name a particular MSH, not just the name of
the corporate entity that owns the MSH.
(Marty, if I am in any way misrepresenting your position, please correct
me.)
-- Dan
However, I'm afraid I didn't make a clearer statement regarding
PartyName.
I was not implying that all information that could be in PartyRef must
be
duplicated in CPP/A. I simply want a human readable description of
PartyID
to accompany PartyID. And I think that could be useful. For example,
to
response to a request from Party A, Party B can either send a Response
or a
Exception or a Signal. As Party A, if I want to see a list of
Exceptions I
have received in the past hour, which one of the following list will
seem a
better option?
List1:
Party2321212
Party4545644
Party91018-3
or
List2:
Compaq
Mom-Pop-at-Corner
Dell
Again, from the technical point of view, it doesn't make any difference.
Because underneath the display, record is probably all identified by
PartyID. It just seems nicer to be able to display list2. ebXML is,
after
all, meant for Business-To-Business applications, which implies,
hopefully,
the large portion of the user will be Business analysts rather than IT
people.
> MWS: Since PartyRef contains the PartyName, there is no reason to add
Can I make that assumption that PartyRef always contains PartyName?
PartyRef points to a Dtd or Schema that can contain any number of
elements.
It is not clear to me that it will definitely contains PartyName. Maybe
I
should make that assumption? If so, shouldn't we make that a mandate
for
the Dtd/Schema that PartyRef points to?
I do realize that having PartyName element or not won't make or break
our
functionality. But I just want to clarify the intention of this
request.
Thanks for bearing with me! :)
Jean
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Wednesday, October 24, 2001 12:50 PM
> To: Jean Zheng
> Cc: 'Dale Moberg'; Arvola Chan; ebxml-cppa@lists.oasis-open.org
> Subject: RE: [ebxml-cppa] Proposed schema changes, plus illustrative
> examp le
>
>
>
> Jean,
>
> **************************************************************
> ***********************
>
> 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/24/2001 01:20:50 PM
>
> To: "'Dale Moberg'" <dmoberg@cyclonecommerce.com>, Martin W
> Sachs/Watson/IBM@IBMUS
> cc: Arvola Chan <arvola@tibco.com>, ebxml-cppa@lists.oasis-open.org
> Subject: RE: [ebxml-cppa] Proposed schema changes, plus
> illustrative
> examp le
>
>
>
> Here is what I can recall for the entire thread.
>
> First of all, I asked if we could define, in addition to PartyRef, a
> definite
> struct that will contain all the partyInfo (contact info,
> etc.). Thus the
> application that imports an CPP/A can import all the partyInfo
> automatically.
>
> MWS: I do not recall this discussion. However, duplicating the
> information
> that is in the PartyRef document is totally unnecessary.
> The application that imports a CPP/CPA can just as easily follow the
> pointer
> to the PartyRef document.
>
> It was defined that way in tpaML.
>
> MWS: The definition in tpaML was unacceptable to everyone
> who looked at
> it,
> both inside IBM and in the ebXML TP team, for all the reasons that I
> mentioned
> in my previous posting.
>
>
> Meanwhile, PartyType doesn't really
> define
> a finite set of "type"s. So it doesn't seem to be very useful at this
> point.
>
> MWS: You mean the type attribute of PartyRef, I agree that
> we need to
> suggest what kind of document PartyRef should be. Saying that it is a
> DTD or Schema should be sufficient since these software can
> distinguish
> among these by looking at them. I'm not sure that it is acceptable to
> make that a normative statement although since this is an XML
> specification,
> limiting the possibilities to DTD and Schema may be OK.
>
> During our f2f, Marty pointed out that there were many issues
> involved in
> defining a definite structure for the contact info, such as
> internationalization.
> So it was proposed that in 1.1 we still use a party's webpage
> url as the
> default
> PartyRef. In other words, it will still be non-machine processable.
>
> MWS: Again, having only a web page URL was a major issue in Vienna.
> Going back to this limitation now will only raise the issue again and
> could result in failure of OASIS to approve the specification.
>
> MWS: If the PArtyRef document is a DTD or Schema, that will also be
> machine processable so there is no reason to require a web
> page in 1.1.
> Adding a non-normative or normative statement that if the
> type attribute
> is present, the PartyRef document be a DTD or Schema is well
> within the
> scope of 1.1.
>
> And I
> am
> to research the schemas out there that already defined for
> Party Contact
> Info.
> Potentially that can be put in 2.0.
>
> MWS: I believe that a single example of a PartyREf document
> is sufficient.
>
> So now, i'm asking, for 1.1 can we have PartyName in addition to the
> PartyRef, which is by default a web page url that can't be used
> programmatically.
>
> MWS: Since PartyRef contains the PartyName, there is no reason to add
> a PartyName element. In addition to all the other reasons already
> mentioned, the duplication can lead to inconsistencies. All that
> has to be done is to prescribe or encourage that a DTD or
> Schema be used.
>
> Does this clear up any confusions?
>
> Jean
>
> > -----Original Message-----
> > From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
> > Sent: Wednesday, October 24, 2001 9:54 AM
> > To: Martin W Sachs
> > Cc: Jean Zheng; Arvola Chan; ebxml-cppa@lists.oasis-open.org
> > Subject: RE: [ebxml-cppa] Proposed schema changes, plus illustrative
> > examp le
> >
> >
> > Yes, I also checked the schema and it is
> > in the 1.0 version. We should review
> > the history of this on Thursday. I
> > will have it on the agenda.
> > Dale
> >
> > -----Original Message-----
> > From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> > Sent: Tuesday, October 23, 2001 9:16 PM
> > To: Dale Moberg
> > Cc: Jean Zheng; Arvola Chan; ebxml-cppa@lists.oasis-open.org
> > Subject: RE: [ebxml-cppa] Proposed schema changes, plus illustrative
> > examp le
> >
> >
> >
> > Dale,
> >
> > The type attribute for PartyRef is already in Ver. 1.0. We
> > added it in
> > Vienna in response to Duane Nickull's issue.
> >
> > 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
> > **************************************************************
> > **********
> > *************
> >
> >
> >
> > Dale Moberg <dmoberg@cyclonecommerce.com> on 10/23/2001 02:37:54 PM
> >
> > To: Jean Zheng <Jzheng@vitria.com>, Arvola Chan
> <arvola@tibco.com>,
> > ebxml-cppa@lists.oasis-open.org
> > cc:
> > 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>