[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
Inline -- Luc
Luc
Clément 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]