[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]