[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [regrep-comresolve] Issue database distribution: 3/15/2002
It does not hurt to list the comments from my meeting with Nita in order to capture them somewhere. As has been pointed out (and my summary document from that meeting also pointed out) much of this will probably be Version 3 stuff. Also, Nita notes in her e-mail that they are still working out the use cases for identification, so they may not be firm yet on what they really need or want. That was obvious during my meeting as well. You may have also noted similar discussions from different groups, for example the e-mail string attached below. This issue will not hold up version 2.0, partly because it is an issue that affects more than one spec from more than one TC and WG, and also because it needs to be resolved and agreed to by multiple teams. -----Original Message----- From: Munter, Joel D [mailto:joel.d.munter@intel.com] Sent: Saturday, March 16, 2002 9:57 AM To: 'Oasis RR Comment Resolution' Cc: Mikula, Norbert H Subject: RE: [regrep-comresolve] Issue database distribution: 3/15/2002 Farrukh, et al We are both referring to the same note [1] from the Oasis ebXML Registry TC chair, Kathryn. We are interpreting it 180 degrees differently. Please indulge me by carefully reading my complete argument below. I would like to expand on my argument a little in support of the proposed discussion on Monday. A key "customer" (BP Catalog Team) of the Oasis V2 Reg/Rep specifications has stated that the design of the unique ID based on UUID does not currently meet their requirements [2]. The V2 Reg/Rep specifications reference the standard and well-used UUID scheme. [3, section 7.3.1] The use/adoption of the UUID scheme by the Reg/Rep team is consistent with how many current specifications (within and outside of the ebXML effort) are structuring the definition of unique keys. Some relevant questions to ask then are: Are the requirements [2] being proposed by the BP catalog team unique to the catalog team? Additionally, were these requirements known to the ebXML effort at its inception or are they new? Other groups across the ebXML effort are discussing this issue also. [4] If the requirement was recorded early in the ebXML [5,6] effort and the current specifications do not meet the requirement, then it should be recorded within this team's V2 issues log. It is my assertion that this requirement did exist early as evidenced by [6, lines 868:872]. If you all believe that the requirements noted in [2] have been added since the ebXML effort began its latter (i.e., V2) phases or the described requirements for identification have been expanded, then I agree that this issue is not unique to the Reg/Rep team but in fact is a limitation of all current ebXML V2 specifications. It shows a great deal of maturity and prudence to show your limitations or to clearly delineate them within an issues log along side the specifications themselves. There is nothing wrong with doing this. [1] http://lists.oasis-open.org/archives/regrep/200203/msg00030.html [2] http://lists.oasis-open.org/archives/regrep/200202/msg00014.html [3] http://www.oasis-open.org/committees/regrep/documents/2.0/specs/ebrs.pdf [4] http://lists.oasis-open.org/archives/ebxml-cppa/200202/msg00065.html [5] http://www.ebxml.org/specs/ebREQ.pdf [6] http://www.ebxml.org/specs/ebTA.pdf Joel -----Original Message----- From: Munter, Joel D [mailto:joel.d.munter@intel.com] Sent: Friday, March 15, 2002 2:26 PM To: 'Oasis RR Comment Resolution' Subject: RE: [regrep-comresolve] Issue database distribution: 3/15/2002 And I based my opinion upon the same criteria so that is why I ask to discuss this on Monday. <snip> What I want to focus on right now is comments that are specific to version 2.0 of the specs. </snip> Joel -----Original Message----- From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] Sent: Friday, March 15, 2002 2:02 PM To: Munter, Joel D Cc: 'Oasis RR Comment Resolution' Subject: Re: [regrep-comresolve] Issue database distribution: 3/15/2002 Joel, I did not make this decision unilaterally. It was based on Katheryn's email at: http://lists.oasis-open.org/archives/regrep/200203/msg00030.html I applied the criterea she had laid out. -- Regards, Farrukh "Munter, Joel D" wrote: > Farrukh, > > I ask you to please place this as a discussion item on the agenda. This is > not your sole decision to make. This is why we have the resolution > sub-team. The fact is that Kathryn discussed this in several team Reg/Rep > meetings and the comments themselves from Nita indicate specific things in > the V2 Reg/Rep that DO NOT meet their requirements. In my mind, that would > make this a valid V2 comment. > > <snip> > We(the ebXML BP Catalog team) had a long conversation last > week with Kathryn about unique identification and what their > scheme should be. We provided her with our requirements for > unique identification that was not satisfied by the current > UUID specification of regrep. The various things that we > touched base upon were:... > </snip> > > I agree that this may in fact become a V3 work item but I strongly recommend > that please record the comment and the agreed disposition. I at least ask > that we discuss this in our sub-team. > > Thanks, > Joel > > -----Original Message----- > From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] > Sent: Friday, March 15, 2002 10:42 AM > To: 'Oasis RR Comment Resolution' > Subject: Re: [regrep-comresolve] Issue database distribution: 3/15/2002 > > I should have noted that I did not include Nita's comments at: > > http://lists.oasis-open.org/archives/regrep/200202/msg00014.html > > because: > > -They were not directed to V2 specs > > -They were part of ongoing discussions between Registry TC and other TCs > focused on what we need to do for V3. > > Please bring to the team's attention any other issues that I might have > missed. Thanks. > > -- > Regards, > Farrukh > > ---------------------------------------------------------------- > 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> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
- From: Duane Nickull <duane@xmlglobal.com>
- To: "William J. Kammerer" <wkammerer@novannet.com>
- Date: Mon, 18 Mar 2002 09:20:23 -0800
William: Your kind offer to pen this document is without equal, therefore, I would formally request that it be done. One minor alteration I would like to bring up. Since the BPSS, Core Components, Registry and CPP/A all make use of a unqiue identifier, I would like to ask you to consider expanding the scope of your work to include these others. The needs are similar - unquely identify a certain item (whether it be a party, core component or a specific BPSSS) and allow the following: 1. A URN based UID or OID that can be used to retrieve additional metadata about the item. 2. Identify it uniquely. Would you consider such? Also - it has been suggested that this document belong in the Archtiecture becuase it spans so many of the other work groups. This makes sense to me and we have agreed to add this work within the UN/CEFACT architecture specification. If no one has any grievances with this, I would like to suggest that is its' home. Duane "William J. Kammerer" wrote: > > I brought the issue up to Dale Moberg for a separate document describing > the oasis:names:tc:ebxml-cppa:partyid-type URN. It can be maintained > independently of the CPP/A specification, and referred to from any of > the CPP/A, Registry and Messaging Services specs. If someone would ask > me nicely to devise the document, I might consider volunteering! > > William J. Kammerer > Novannet, LLC. > +1 (614) 487-0320 > +1 (614) 638-4384 (c) > +1 (928) 396-6310 (FAX) > > ----- Original Message ----- > From: "Christopher Ferris" <chris.ferris@sun.com> > To: "William J. Kammerer" <wkammerer@novannet.com> > Cc: "OASIS ebxml-cppa" <ebxml-cppa@lists.oasis-open.org> > Sent: Monday, 18 March, 2002 11:17 AM > Subject: Re: [ebxml-cppa] CPPA version 1.10 > > Where are the normative URN's for the various types defined? > The spec just cites as an example the use of the URN you cite. > It seems clear to me that these URN's need to be formally > declared and assigned specific an unambiguous definitions. > > Cheers, > > Chris > > ------------------------------------------------------------------------ > > Subject: Re: [ebxml-cppa] CPPA version 1.10 > Date: Mon, 18 Mar 2002 11:04:52 -0500 > From: "William J. Kammerer" <wkammerer@novannet.com> > Organization: Novannet, LLC > To: OASIS ebxml-cppa <ebxml-cppa@lists.oasis-open.org> > References: <OE673yZty1sh4AsK6Ex000107f3@hotmail.com> > <3C9240B6.7744EC96@xmlglobal.com> > > The ebxml-cppa TC already has an OASIS URN namespace defined for > describing ID domains: urn:oasis:names:tc:ebxml-cppa:partyid-type. > There's no need for the registrar of a particular domain (e.g., D & B > for DUNS, or the IRS for Federal Tax IDs) to define URNs. Currently, > the CPP URN describes the use of a DUNS, e.g., > > <tp:PartyId tp:type="urn:oasis:names:tc:ebxml-cppa:partyid-type:duns"> > 123456789</tp:PartyId> > > I've asked the CPP/A group to define a few additional domains. HIPAA > EDI will require a number of domains available in the X12 Interchange ID > Qualifier, in addition to the already existing DUNS. I've listed the > X12 qualifier code, the description, and examples, if available: > > 01 Duns (Dun & Bradstreet), e.g., DUNS 072930527 is Novannet, LLC > 14 Duns Plus Suffix DUNS+4, e.g.,1465226281601 Kroger Distribution > Center at 4450 Poth Road Columbus, OH 43213 > 20 Health Industry Number (HIN), http://www.hibcc.org/hin.htm > (602-553-8552), .e.g., G8TT9DW00 is Novation > 27 Carrier Identification Number as assigned by Health Care Financing > Administration (HCFA), e.g., 30002 is Aetna Life and Casualty Co. > 28 Fiscal Intermediary Identification Number as assigned by Health > Care Financing Administration (HCFA) > 29 Medicare Provider and Supplier Identification Number as assigned > by Health Care Financing Administration (HCFA) > 30 U.S. Federal Tax Identification Number, e.g, UCLA Orthopaedic > Surgery Medical Group is 954505291 > 33 National Association of Insurance Commissioners Company Code > (NAIC), e.g, Prudential is NAIC # 68241, and Highmark is 54771. > > It would make sense if the other ebXML groups (Messaging Services and > Registry) used this same URN: The OASIS/ebXML Registry Information Model > v2.0 uses a text string (e.g., "DUNS", "Social Security #") in section > 7.9 Class ExternalIdentifier, and the Message Service Specification > Version rev C uses an "imaginary" URN in PartyId type. > > William J. Kammerer > Novannet, LLC. > +1 (614) 487-0320 > +1 (614) 638-4384 (c) > +1 (928) 396-6310 (FAX) > > ----- Original Message ----- > From: "Christopher Ferris" <chris.ferris@sun.com> > To: "Duane Nickull" <duane@xmlglobal.com> > Cc: "Martin W Sachs" <mwsachs@us.ibm.com>; "David Fischer" > <david@drummondgroup.com>; "CPPA" <ebxml-cppa@lists.oasis-open.org> > Sent: Friday, 15 March, 2002 06:15 PM > Subject: Re: [ebxml-cppa] CPPA version 1.10 > > again, it wasn't my intent that the ssn or ein be used, but > it was an example of an authority that had an identification > scheme with a managed namespace. It was just an example. > > The point is that D&B has such a namespace and if they > would simply register a URN scheme with IANA then the > issue would be moot. In the absense of a URI/URN scheme > we and many before us have resorted to code sets (like > 'DUNS') that in reality are just another value in a namespace > which is not identified. > > Maybe OASIS should simply use its namespace (the regrep team > maybe) to establish a branch that could be used to assign > identifiers for codes like 'DUNS'... > e.g. urn:oasis-open.org:tc:regrep:foriegn-namespaces:duns > which we could use as values for the 'type' attribute > and then make the 'type' attribute of type xsi:anyURI and > be done with it. > > Cheers, > > Chris > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> -- CTO, XML Global Technologies **************************** Transformation - http://www.xmlglobal.com/prod/foundation/ ebXML Central - http://www.xmlglobal.com/prod/central/ ---------------------------------------------------------------- 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