RE: [ebxml-cppa] CPPA version 1.10

[David Fischer <david@drummondgroup.com>]

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/