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

["Von Riegen, Claus" <claus.von.riegen@sap.com>]

Paul,

I support almost all your ideas. Some comments <CvR>inline</CvR>.

Claus

-----Original Message-----
From: Paul Denning [mailto:pauld@mitre.org] 
Sent: Mittwoch, 14. Mai 2003 22:37
To: 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


At 08:44 PM 2003-05-13, Luc Clement wrote:
>Please review this prototype.

The prototype has a section on "published tModels".

It has "Registered Location:".   I think "published" should imply to the UBR.

<CvR>I have the same assumption - we should document all "common" tModels in the URB.</CvR>

It is sort of like an IANA type of thing.  We're talking about "well-known" 
tModels.

What makes them "well-known"?  I think it is that they are published in the 
UBR.

<CvR>Publishing to the UBR is necessary, but is not sufficient to make a tModel "common". There are some necessary technical criteria such the ones you list below and there are some necessary semantical criteria. Both sets of criteria should be developed and agreed upon by the UDDI TC in a way that the overall process works. The bar should not be too low (so that we can't cover all requests) and it should not be too high (so that we prevent people from even making requests.</CvR> 

If I have a v2 tModelKey assigned by the UBR, then I can use that tModelKey 
in a private UDDI registry.  That is, in a private UDDI registry I can 
create a tModel and give it the same tModelKey as the corresponding tModel 
published in the UBR.

That way, applications that are designed to discover services at runtime by 
searching a UDDI registry for a tModelBag (late binding) could use the same 
tModelKeys whether they search UBR or other private UDDI registries.

<CvR>That's a very sensible goal.</CvR>

I also think that the "published tModels" section should be derived 
directly from the UBR.  If I search UBR for tModels whose categoryBag 
include keyValue="categorization" for the uddi-org:types taxonomy, I should 
be able to get the same information.

<CvR>Actually, we want to promote tModels of every UDDI Type (including service types, ID systems, relationship types etc.) to be "common".</CvR>

You would probably want some method of scrubbing the UBR data such that the 
tModels you highlight on the proposed uddi.org page would not contain bogus 
taxonomies.  I don't think you want to limit it to only those taxonomies 
that are "checked" by UBR.  So some "unchecked" taxonomies should be allowed.

Proposed criteria for highlighting on uddi.org:
1.  tModel published in UBR
2.  tModel categoryBag includes uddi-org:types "categorization"
3.  tModel categoryBag includes either uddi-org:types "checked" or "unchecked"
4.  tModel overviewURL is not a broken link or empty.
5.  tModel overviewURL retrieval returns an "appropriate" representation 
(see below)

<CvR>Your items 4. and 5. are a sensible extension to the list I included in my response to Luc's initial request. However, item 5. is really hard to check programmatically.</CvR>

A TN should describe what is an appropriate representation for the 
overviewURL, like wsdlSpec points to WSDL.

The TN for providing a taxonomy in UDDI v2 [1] currently does not say much 
about describing the taxonomy.  Perhaps that TN should be updated to 
specify that the overviewURL points to something like RDDL [2], which would 
be a human readable document with machine readable links like <xhtml:a 
rddl:nature="..." and rddl:purpose="..." href="...">.  The href could point 
to an XML document that contains the value set, and rddl:nature could refer 
to its format.  Various formats could be considered "appropriate" since 
UDDI Spec TC will not have time to define (and agree upon) one.  If UDDI 
Spec TC does come up with a new XSD for external taxonomies, then it can be 
added to the list of "appropriate" rddl:nature's.  If someone has a 
taxonomy that is "unchecked" in UBR, but "checked" in a private UDDI 
registry, then they may be able to publish an appropriate href on the 
Web.  For example, if using Systinet WASP UDDI, we might have 
rddl:nature="http://www.systinet.com/uddi/web/doc/uddi/taxonomy.xsd"

<CvR>Interesting idea. I am not familiar with RDDL at all. Whether or not it can be applied to our concept depends on the availability of corresponding tool support, IMO.</CvR>

Anne suggested a UDDI registry separate from UBR to store the set of 
approved tModels.  I don't like this idea (see criterion 1 above).  I want 
to be able to search UBR for the criteria listed above and derive the same 
list of tModels that appear on uddi.org.

<CvR>+1</CvR>

UDDI Spec TC should build its page using tools that search UBR for tModels 
matching these criteria.  This implies that these tools follow 
(dereference) the overviewURL, and check it against whatever is deemed 
"appropriate".  If its RDDL, then the tools would also need to follow the 
appropriate href's, and perhaps validate the XML against a schema 
(identified via rddl:nature).  Doing this extra level of checking should 
weed out most if not all of the junk in UBR (at least as far as getting a 
good list of taxonomy tModels).

<CvR>Again, I don't think that the process can be carried out by tools only. We need a) some higher-level concept on how to limit the requests to a reasonable number and b) we need to manage requests for V3 key derivations. The latter can not be carried out by starting with a published V2 tModel.</CvR>

UDDI v3 tModels could have a useType="rddl" for an overviewURL that points 
to RDDL.  Might also want to update the v3 value set TN [3].

[1] 
http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-taxonomy-provider-v100-20010717.htm
[2] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0213
[3] 
http://oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-valuesetprovider-20030212.htm

Paul