[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] Use of UDDI.org as a means of promoting TC, UBR, Std Group and Consortium tModels and Value Sets
Tom, I see a potential problem with using the UBR in that there is no legal relationship between the TC or the UDDI Member Section and the UBR OC. It would be useful to establish such a relationship, covering the status of the UBR and the terms under which the TC and/or the Member Section publish to the UBR. Daniel > -----Original Message----- > From: Tom Bellwood [mailto:bellwood@us.ibm.com] > Sent: Wednesday, May 14, 2003 11:58 PM > To: Anne Thomas Manes > Cc: uddi-spec@lists.oasis-open.org > Subject: RE: [uddi-spec] Use of UDDI.org as a means of > promoting TC, UBR, Std Group and Consortium tModels and Value Sets > > > > > > > Hi Anne, > > I think I mostly agree with your first point, in that we > shouldn't be so particular, although I still think that if > we're going to essentially advertise these tModels at the TC > level, we have some obligation to insure that they are not frivilous. > > As for your second point, you have the right idea about > creating a business relationship in the registry to > essentially "certify" that the tModel has been approved by > the TC. That's about the only way to address the issue in an > open V2 implementation. What you've got wrong is that there's > no way to do it or that it is somehow unsupported. This is a > basic V2 feature, and the UBR fully supports it. I still > believe that the UBR is the best place for this information > to go. It is the most publicly recognized UDDI > implementation of which I am aware that is intended for use > by all, and it is still inexorably linked to our TC. I would > suggest that our TC use it > to its best advantage in this case. Setting up and operating a > high-availability registry is not a cheap thing to do. > Spending our TC's resources to essentially duplicate what we > already have available seems wasteful to me. > > Thanks, > Tom Bellwood Phone: (512) 838-9957 (external); TL: 678/9957 > (internal) > Co-Chair, OASIS UDDI Specification TC > STSM - Emerging Technologies > IBM Corporation > > "Anne Thomas Manes" <anne@manes.net> on 05/14/2003 11:00:49 AM > > To: <uddi-spec@lists.oasis-open.org> > cc: > Subject: RE: [uddi-spec] Use of UDDI.org as a means of > promoting TC, > UBR, Std Group and Consortium tModels and Value Sets > > > > > Claus/all, > > I'm really pleased to see this moving along so quickly. But > I have a couple of concerns. > > 1- This statement makes me a bit uneasy: "The announcement > of tModel availability is limited to tModels that represent a > well-known concept and/or are owned by a well-known > standards group or consortium (note that “well-known” may be > limited to an industry, a geographical region or other contexts)." > > I wouldn't want to restrict this effort to "well-known" > consortia. I think it's quite reasonable for a local SIG to > develop a useful value set and propose its public > availability. I would prefer that we define a public process > that permits anyone to make a proposal. If a standards group > submits a proposal that applies to its specific industry > segment, we should accept it without question once we've > verified that it is a well-formed value set. If the proposal > has cross-industry application or if it has been submitted > by an individual or informal group, then we should evaluate > it and solicit comments and input -- the same way that we > would handle a proposed technical note. > > 2- I'm also very hesitant to use the UBR as the repository > for these "approved" value sets. It's very difficult to > distinguish valid information from test/junk information in > the UBR. There's no way of indicating in the UBR that a > tModel has been "approved", and I don't think it's > appropriate to require a user to view a page on the UDDI.org > member section page to determine the status of a tModel in > the UBR. You would need the equivalent of a business > assertion between a business entity representing the > UDDI-spec TC and the approved tModel -- but that's not > supported. That's why I recommended a separate UDDI registry > operated by the UDDI.org members as the registry of record. I > think it's appropriate to require that the value set first > be registered in the UBR as part of the application process, > but once the tModel has been "approved", it should be > registered in the UDDI .org member registry. > > Anne > -----Original Message----- > From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com] > Sent: Wednesday, May 14, 2003 6:28 AM > To: 'Luc Clement'; uddi-spec@lists.oasis-open.org > Subject: RE: [uddi-spec] Use of UDDI.org as a means of > promoting TC, UBR, Std Group and Consortium tModels and Value Sets > > > Luc, > > Thanks for your proposal. I believe that it is important and > already well structured. I took the liberty to work out the > details of your Prototype page. Please find an updated page attached. > > Claus > -----Original Message----- > From: Luc Clement [mailto:lclement@windows.microsoft.com] > Sent: Mittwoch, 14. Mai 2003 02:45 > To: uddi-spec@lists.oasis-open.org > Subject: [uddi-spec] Use of UDDI.org as a means of promoting > TC, UBR, Std Group and Consortium tModels and Value Sets > > > (Apologies for my last and premature mail) > > A few meetings ago, the topic of where to post non-normative > tModels came up in a discussion; we never concluded this > discussion. I'd like to revive it and obtain your input on > the following. > > Background > As some of you may know, during the course of the v3 spec > development, we removed from the spec those tModels and value > sets that were not considered appropriate to make normative > in favour of having the UDDI Business Registry (UBR) to > manage these. They include the following: 1 UDDI Business > Registry Value Set tModels: Category System, Identifier > Systems and Categorization Groups > > 1.1 North American Industry Classification System (NAICS) > 1997 Release 1.2 United Nations Standard Products and > Services Code System (UNSPSC) Version 7.3 1.3 ISO 3166 > Geographic Code System 1.4 ISO 3166 Code Derivation for > Business Locations 1.5 ISO 3166 and UNSPSC Code Group System > 1.6 World Geodetic System 1984 1.7 WGS 84 Latitude Code > System 1.8 WGS 84 Longitude Code System 1.9 WGS 84 Altitude > Code System 1.10 Geographic Precision Code System 1.11 UDDI > Business Registry Postal Address Structure 1.12 Dun & > Bradstreet D-U-N-S® Number Identifier System 1.13 Thomas > Register Supplier Identifier Code System 1.14 ISO 6523 > International Code Designator (ICD) System > > 2 UDDI Business Registry Core tModels > > 2.1 Domain Key Generator for the UDDI Business Registry > Domain 2.2 UDDI JIS X 4061 Japanese sortOrder qualifier The > UBR's Operator's Council is currently in the process of > reviewing these tModels in support of its UDDI v3 deployment > work. This topic is long overdue. TC, Standards Groups and > Consortium Needs As we've discussed and continue to > encounter, the TC, other standards groups and consortium > need a place where they can collect and promulgate the > existence of their tModels and value sets (e.g. WSDL v2 TN, > ebXML TN, etc). Proposal The UBR Operator's Council is > considering asking the UDDI Steering Committee to post UBR > tModels on UDDI.org. At the same time, the OC discussed the > need/desire for the TC/Consortium to have a similar forum > and thought that we should consult the TC. > > To this end, the OC has created a prototype page to be added > to the UDDI.org site; please find it attached. The prototype > suggests the addition of a "Common tModels" navigation link > which displays the content of the attached. > > Please review this prototype. This matter will be put on the > agenda for the next TC call. Action Required A. The OC is > soliciting your support and interest for this; while it can > proceed independently from the TC, it would be best to > coordinate this. > > B. We need to discuss the criteria for what gets published > on the page; I would expect the Steering Committee to be the > gate keeper but they would require guidance from the TC on > matter of criteria > > As a next step once we complete this discussion and if the > TC is favourable to posting such information, the next step > would be for the TC (and the OC) to make a request to the > UDDI-SC asking for this content to be posted. > > For your consideration. > > Luc > > > Luc Clément > Microsoft > Co-chair, OASIS UDDI Spec TC > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]