RE: [uddi-spec] Use of UDDI.org as a means of promoting TC, UBR, Std Group and Consortium tModels and Value Sets

["Anne Thomas Manes" <anne@manes.net>]

Tom,

I agree that it would be much more convenient to use UBR, but how can you "certify" an individual tModel? Business assertions exist between business entities, not between a business entity and a tModel. (Unless I'm missing something...)

Anne

> -----Original Message-----
> From: Tom Bellwood [mailto:bellwood@us.ibm.com]
> Sent: Wednesday, May 14, 2003 3: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
> 
>