OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[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.


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

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


John Colgrave

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

01/03/2005 21:06 

	<Tong_Jin@bah.com>, <uddi-spec@lists.oasis-open.org> 
	RE: [uddi-spec] Groups - Property Support in UDDI



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


[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

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 Description:
This proposal describes changes to UDDI spec to support generic meta
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:

Download Document:  

PLEASE NOTE:  If the above links do not work for you, your email
may be breaking the link into two pieces.  You may be able to copy and
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]