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

["Luc Clement" <lclement@windows.microsoft.com>]

Inline -- Luc

Luc Clément
Microsoft
Co-chair, OASIS UDDI Spec TC

---

From: Max Voskob [mailto:max.voskob@paradise.net.nz]
Sent: Tuesday, May 13, 2003 18:28
To: Luc Clement; uddi-spec
Subject: Re: [uddi-spec] Use of UDDI.org as a means of promoting TC, UBR, Std Group and Consortium tModels and Value Sets

Luc, it all makes perfect sense and I think the TC should not stay away from this activity.

I have an old question, tho...

What's behind a tModel for taxonomy?  How can I find out the content of a particular taxonomy? 
[LC] I meant to state this but fell short of it. You're absolutely right.  

 

It is not enough to just publish a tModel. It gives no information what data is behind the tModel and gives no option for private implementation of a UDDI server to replicate the taxonomies on site. Neither it allows a UDDI client / browser to browse the taxonomies, even if the tModel is published on UDDI.org

 

If we are going to discuss publishing of the tModels, would it make sense to come up with a temporary schema for taxonomy description and give everyone access to the content of the taxonomies in the meantime?

 

Almost every UDDI vendor has its own schema for import/export of taxonomies. We could combine their experience and produce something simple until v.4 delivers more powerful taxonomy management.  

 

My suggestion:

 

1. produce and publish a non-normative schema for taxonomies

2. publish the schema with necessary documentation on UDDI.org

3. publish XML files with taxonomy content on UDDI.org as specified by the schema

 

Not sure there is any interest for our TC to do so, but I thought it would be a good idea ...
[LC] What you propose sounds reasonable and indeed was the intent of forming a value set subcommittee. I'd propose that you set out to work on this with an eye towards v4; there may be some interim steps along the way that might satisfy immediate needs which we should consider and capitalize on.

 

This is not going to be without challenge. This TC emits "Committee Specifications", "Best Practices" and "Technical Notes" each of which goes to vote. BPs and TNs are non normative as you know. Working towards a TN is what's called for here. The challenge as I see it is producing a work that stays clear of defining a normative format (or schema) and yet compeling enough for folks to use. As you work through this, one needs to remain true to the intent of a TN: "A Technical Note is a non-normative document accompanying the UDDI Specification that provides guidance on how to use UDDI registries. While Technical Notes represent the UDDI Spec TC’s view on some UDDI-related topic, they may be prospective in nature and need not document existing practice."

 

Perhaps, if the work is cast as an intermediate format to exisiting value sets formats (e.g. unspsc, iso3166, etc etc) and/or value set schemas (i.e. those published by standards bodies or vendors) this may prove to be very valuable work; the risk is producing a work that does not get wide support, creates uncertainty and makes certain individuals become catatonic.

 

Makes sense?

 

Cheers,

Max