[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] Groups - Property Support in UDDI (uddi-spec-tc-prop030-property-and-significant-keyname-20050225.doc) uploaded
Hello group, The key features in this proposal are: 1 Provide a way to define the type information of a property set, including name and data type of each property. This is similar to a struct/class definition in C/OO language. A UDDI registry can then use this information to validate published information to rule out invalid properties (invalid property/key name and invalid key/data value). A UDDI/registry user interface can even use this type definition information to build a more user friendly UI, e.g., to automatically build a GUI form. An alternative is to define one tModel for each individual property, but it often leads to tModel def proliferation. Also grouping related tModel keys and managing their relationships through a web of keyed references could be overly complicated compared to a struct/class type of property set definition. 2 Grouping of sub properties. The definition of a property set includes what are the allowed sub properties and their cardinalities. A UDDI registry can use such definitions to do type checking. In comparison, using current keyed reference group, there is no way to control what and how many keyed references can go inside a group. For example, for a group to represent a US address property set, it is syntactically legal to put three zip code lines in it and to include a keyed reference that has no relation to address information at all. 3 Propose to optionally request name matching during searching. This requirement is particularly useful when coupled with the property set concept, where each individual sub property is identified by the key name. The proposal has an example where the longitude and altitude numbers are two distinct properties under one property set. In terms of searching, key name (property name) sensitivity is a must to make the search accurate (when you search on longitude number, you don't want match an entry with latitude). The actual motivating use case we had is for a "point of contact" meta data property set, where a meta data standard we are following requires "first name" and "last name" as two distinct sub properties. A person whose last name is "Bob" is always returned when people are really searching services whose POC's first name is Bob under current UDDI specs. An alternative approach I have seen is to define a tModel for each individual sub property and then there is no need to match (or even supply) key name anymore. The argument against it is in point 1 above. The key benefits of this proposal, we believe, are: * to provide a controlled and scalable way of defining meta data property/property set, promoting meta data definition to the center stage, and * to support such meta data description and searching in UDDI. Hope this answers some of the questions. As to some of the wording in the proposal, we originally intend to submit this as a TN for the current spec(s). Due to the spec change effect, we re-fit the document into a v.Next proposal. So it needs an astute review process from the TC. Thanks, Jin Tong ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Phone 703-917-2839 || Booz | Allen | Hamilton Fax 703-902-3457 || 8251 Greensboro Drive Email Tong_Jin@bah.com || McLean VA 22102 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ________________________________ From: John Colgrave [mailto:colgrave@uk.ibm.com] Sent: Tuesday, March 01, 2005 5:07 PM To: Von Riegen, Claus Cc: Brown Chris; Tong Jin; uddi-spec@lists.oasis-open.org Subject: RE: [uddi-spec] Groups - Property Support in UDDI (uddi-spec-tc-prop030-property-and-significant-keyname-20050225.doc) uploaded The document is written as a V4 proposal but it says that the main version of UDDI discussed is V2 with guidance on using V3. I don't think this topic warrants updating either the V2 or V3 OASIS Standards. In the context of V4, I think the new features are the typing of keyValue values and the concept of property sets. A keyedReferenceGroup could be used to represent a property, without the type information, but as keyedReferenceGroups cannot be nested there is no way to represent a property set. I think we have discussed before whether there should be special support for properties, making the keyName significant and typing keyValue values but I don't think any compelling use cases emerged for any of these. Regards, John -------------------------------------------------- John Colgrave IBM "Von Riegen, Claus" <claus.von.riegen@sap.com> 01/03/2005 21:06 To <Tong_Jin@bah.com>, <uddi-spec@lists.oasis-open.org> cc <brown_chris@bah.com> Subject RE: [uddi-spec] Groups - Property Support in UDDI (uddi-spec-tc-prop030-property-and-significant-keyname-20050225.doc) uploaded Jin, Thanks for your proposal, which lists a number of quite useful examples. However, I am actually wondering why you didn't use category group systems to model properties and property sets directly. Existing proposals already cover examples like the modeling of postal addresses [1] and geographic locations (second example in [2]). What would be needed in addition to meet the requirements you list in your proposal? Thanks, Claus [1] http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/9799 /UDDI_Taxonomy_tModels.htm#postal [2] http://uddi.org/pubs/uddi-v3.0.2-20041019.htm#_Toc85908416 -----Original Message----- From: Tong_Jin@bah.com [mailto:Tong_Jin@bah.com] Sent: Montag, 28. Februar 2005 16:25 To: uddi-spec@lists.oasis-open.org Cc: brown_chris@bah.com Subject: [uddi-spec] Groups - Property Support in UDDI (uddi-spec-tc-prop030-property-and-significant-keyname-20050225.doc) uploaded The document named Property Support in UDDI (uddi-spec-tc-prop030-property-and-significant-keyname-20050225.doc) has been submitted by Mr Jin Tong to the OASIS UDDI Specification TC document repository. Document Description: This proposal describes changes to UDDI spec to support generic meta data with UDDI entities. Specifically, it describes a methodology to model structured metadata properties as property sets in UDDI, and provides guidance on UDDI registry's handling of such metadata properties during publishing and inquiry. View Document Details: http://www.oasis-open.org/apps/org/workgroup/uddi-spec/document.php?docu ment_id=11602 Download Document: http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/1160 2/uddi-spec-tc-prop030-property-and-significant-keyname-20050225.doc PLEASE NOTE: If the above links do not work for you, your email application may be breaking the link into two pieces. You may be able to copy and paste the entire link address into the address field of your web browser. -OASIS Open Administration --------------------------------------------------------------------- To unsubscribe, e-mail: uddi-spec-unsubscribe@lists.oasis-open.org For additional commands, e-mail: uddi-spec-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]