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 || McLean VA 22102
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
________________________________
From: John Colgrave [mailto:]
Sent: Tuesday, March 01, 2005 5:07 PM
To: Von Riegen, Claus
Cc: Brown Chris; Tong Jin;
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" <>
01/03/2005 21:06
To
<>, <>
cc
<>
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: [mailto:]
Sent: Montag, 28. Februar 2005 16:25
To:
Cc:
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?document_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:
For additional commands, e-mail:
