[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-cppa] Proposed schema changes, plus illustrative examp le
Very true. Getting "PartyName" is by no means the final solution, but I'd like to think it is a good starting point. Plus, current CPP/A does contain information on Endpoint and DeliveryChannel. They can be combined with PartyName to help user narrow down the problematic area at a first glance. jean > -----Original Message----- > From: Dan Weinreb [mailto:dlw@exceloncorp.com] > Sent: Thursday, October 25, 2001 10:45 AM > To: Jzheng@vitria.com > Cc: mwsachs@us.ibm.com; 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> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC