Re: Some Party questions

[Duane Nickull <duane@xmlglobal.com>]

Marty:

While this notion is probably acceptable to some degree,  I want to point out the uses
for the PartyID.

1. PartyID is an element within the CPP which identifies the party or organization to
whom the CPP belongs.  If a PArty has muyltiple CPP's it is possible that they would use
the same Party Identifier in each CPP (after all - it is the same party).

2. Since it is  possible that a party might have 2 or more CPP's (for different divisions
or ???), it is necessary to know which CPP you are referring to when proposing a CPA
which the company is a party to.

3.  Unless the PartyID is different for each CPP document instance, it will not be
sufficient to uniquely identify a specific CPP document.  Therefore, the CPA negotiation
will be in confusion becuase the CPA examiner will not be able to determine if the CPA is
legal within the capabilities expressed in a certain CPP document.

I therefore assert that the CPP document requires a Unique Idenifier if it is to be used.

Maybe this can be in the form of a urn:dunsID PLUS companydivisionID therefore making
each company responsible for uniquely identifying its' own CPP's.  In previous experience
however,  I would suggest this may fail.  Why?  Simply becuase it can.

Thoughts?

Duane

Martin W Sachs wrote:

> This will be rejected by the ebxml-core list.  Someone please repost.
>
> Duane,
>
> Global uniqueness of a Party's CPPs is partially assured by the uniqueness
> of the PartyId.  The question is what, if anything, needs to be prescribed
> to ensure that the CPPs are uniquely defined relative to the PartyId.
> Possibly it is sufficient that if a Party's multiple CPPs are stored in a
> registry or repository, they are distinguishable by however the registry
> identifies them.
>
> TP team, please comment on any need to prescribe more on this.
>
> 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
> *************************************************************************************
>
> Duane Nickull <duane@xmlglobal.com> on 03/31/2001 12:38:44 AM
>
> To:   tboyle@rosehill.net
> cc:   ebxml-tp@lists.ebxml.org, ebxml-core@lists.ebxml.org
> Subject:  Re: Some Party questions
>
> Todd:
>
> I have been raising this question for a long time.  I don't think that
> there is any need to actually retrieve something from DUNS however, the
> number must be able to be used as a root for a URN that is unique.  The
> secondary URI reference is used for retrieving information about the
> party.  This is the way it has been explained to me anyways.
>
> Therefore,  the IANA registration will just ensure that DUNS has control
> over the ability to issue Globally unique identifiers for company's.
> No information may ever be actually retrieved from DUNS or any DUNS
> registry service.
>
> PROBLEM:  Duns numbers are very hard to get for SME's.  It is a possible
> roadblock for participation in ebXML if it is required to have a DUNS
> number.  I also think that DUNS does not issue numbers in some
> countries.  I suppose that DUNS is just one possible idenitification
> sheme. It is presumed that there are alternative identification shemes
> as well?????
>
> Some issues.
>
> 1. Has anyone in ebXML EVER talked to anyone at DUNS to ask about this
> IANA registration?
>
> 2. When company's make more than one CPP,  how do we distinguish them
> apart?  They will need globally unique identifiers.
>
> Duane
>
> > Actually this raises the question, what data will be returned by such
> > directory
> > services??  No doubt every Directory willuse a different HTTP, SOAP,
> > etc.
> > request and response, and record format :-(  Every application will
> > have to
> > keep a database of the element names returned by each directory.
> >
> > --------------------------
> > 2.  The Core components initial catalog, Appendix A. contained the
> > following.
> > I presume they are talking about schemes such as DUNS, EAN, etc
> >
>
>   code           A value from a
>                  code list.
>   code.details   The
>                  information
>                  required to
>                  associate a
>                  code with it's
>                  meaning.
> >
> >
>
>   code list                     A list of codes.
>   code list. identifier         The name of a list of codes.
>   code list. agency.            An agency that maintains one or more
>   identifier                    code lists.
> >
> > It seems to me, in the above example from CPP/CPA that 123456etc is a
> > "code".
> >
> > The "code details" will be a differently shaped object for every code
> > list.
> > IN this case it would be a whole party record, in whatever shape
> > returned
> > by DUNs or whoever.
> >
> > The "code list identifier" might be "DUNS"?  Where are the valid
> > values
> > of  "code list identifiers"?  What if somebody says "D-U-N-S"...  or,
> > is this intended to be based on EDIFACT 3055 codes?
> > http://www.unece.org/trade/untdid/d99b/tred/tred3055.htm  I noted,
> > out of all those agencies, IANA is not listed, or a good many other
> > agencies. UDDI, OASIS aren't either...
> >
> > Finally--I think this core component needs another attribute, "code
> > list.agency.Uri"
> >
> > Sorry for my ignorance, many thanks for any comments.
> >
> > TOdd
> > Todd Boyle CPA   (425) 827-3107
> > 9745-128th Av NE, Kirkland WA 98033
> > tboyle@netaccount.com  http://www.netaccount.com/
> > tboyle@rosehill.net  http://www.gldialtone.com/
> >
> >
> >
> >
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-tp-request@lists.ebxml.org