[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-cppa] CPPA version 1.10
Marty, I am all for some means of clarifying/standardizing what goes into PartyId & type. I am very much against limiting what can be put into those fields to only what is registered. There is nothing wrong with using a type of "DUNS" or "urn:duns" as long as the two parties agree to what this means. If we can pre-define the major categories, so much the better. Your last paragraph: ...someone can't use their own numbering system. is exactly what I was afraid was happening. Regards, David. -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Thursday, March 21, 2002 12:18 PM To: David Fischer Subject: RE: [ebxml-cppa] CPPA version 1.10 David, Let's not forget interoperability. Whatever is expressed for the PartyID type and value has to be understood by both parties to a business arrangement. So, one party cannot unilaterally put in whatever he/she wants. You might as well replace type by a mandatory phone call between the parties to explain each other's partyId. If we were to stick with simply character strings for the partyId type, we would have to solve the dillema in th first paragraph by including a set of definitions of the type values in the msg or CPPA spec. It would say "DUNS" means a Dun and Bradstreet number. That's exactly what we are trying to avoid. In answer to your last paragraph, someone can't use their own numbering system. That would get back into the dilemma of the first paragraph above. That's precisely why we need a means of registering the URIs, so that any trading partner in the universe can understand them. 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 ******************************************************************************** ***** "David Fischer" <david@drummondgr To: "Duane Nickull" <duane@xmlglobal.com>, Martin W Sachs/Watson/IBM@IBMUS oup.com> cc: "Arvola Chan" <arvola@tibco.com>, "Christopher Ferris" <chris.ferris@sun.com>, "Dale Moberg" <dmoberg@cyclonecommerce.com>, "CPPA" <ebxml-cppa@lists.oasis-open.org> 03/21/2002 12:28 Subject: RE: [ebxml-cppa] CPPA version 1.10 PM Yes, this was a concern expressed during the discussions -- does DUNS mean Dun & Bradstreet Number or does it mean David's Unique Numbering System? I am actually glad this is being clarified. My only concern is a requirement for the type to be anyURI which is more restrictive than tns:nonEmptyString. I disagreed with Dale that the MSH could do something other than what is in the CPA. The MSH at this point is tightly coupled to the CPA so whatever restrictions are in the CPA will directly affect Messaging. What is to be done with numbering systems/authorities which are not defined by our URI? If we require type to be a URI, does this mean that someone else who wants to use their own numbering scheme must create a valid URI for that scheme rather than just use some agreed upon string -- like DUNS? I suppose the URI/URN does not actually have to resolve to anything. If this is the case, we should say so somewhere. Regards, David. -----Original Message----- From: Duane Nickull [mailto:duane@xmlglobal.com] Sent: Thursday, March 21, 2002 10:51 AM To: Martin W Sachs Cc: David Fischer; Arvola Chan; Christopher Ferris; Dale Moberg; CPPA Subject: Re: [ebxml-cppa] CPPA version 1.10 Martin W Sachs wrote: > > David, > > The problem with using type="DUNS" is that the values are arbitrary > character strings; >>>>>>>>> Another problem is that DUNS is not a defined value anywhere. What does it stand for? We might assume it means a Dun & Bradstreet number but this is not represented in the spec anywhere. IF I chose to use Duane's Unique Numbering System (DUNS), it may collide with someone elses' unique value. First define the requirements for what this has to do. Then th eanswer is evident. William Kammerer will write a paper with the ideas submitted by Chris Ferris, myself and many others. This should solve it. D- -- CTO, XML Global Technologies **************************** Transformation - http://www.xmlglobal.com/prod/foundation/ ebXML Central - http://www.xmlglobal.com/prod/central/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC