DISCLAIMER: the following is not an attack on the proposal. I'd just like
to understand whether we can achieve the desired results (and possibly more)
using an existing structure: the keyedReferenceGroup.
Consider an example you mention in your email - lat / long coordinates
(let's ignore WGS 84 - the keys are too long...). If we make keyName
significant, then yes, you could have (abbreviations used because I'm a lazy
typist!):
<keyedReference name="lat" value="15.1"
tModel="myLatLongPoint">
<keyedReference name="long" value="12.2"
tModel="myLatLongPoint">
This has the disadvantage that we need extra validation (not standard UDDI)
to check that a given entity has exactly one KR with name="lat" and one with
"long". That doesn't thrill me. Nor does the fact that these two items are not
noticeably tied together, except through use of the same tModel key.
As a keyedReferenceGroup, on the other hand, we can have:
<keyedReferenceGroup tModel="myLatLong.point">
<keyedReference name="random" value="15.1"
tModel="myLatLong.lat">
<keyedReference name="random" value="12.2"
tModel="myLatLong.long">
</keyedReferenceGroup>
Here we have the two values visibly tied together, which is nice (not
compelling, just nice). We can validate this keyedReferenceGroup as a unit,
which is also nice. And it uses a facility which is already part of UDDI -
that's good. It also means that we might have other types that use these tModels
- we can have:
<keyedReferenceGroup tModel="myLatLong.3Dpoint">
<keyedReference name="random" value="15.1"
tModel="myLatLong.lat">
<keyedReference name="random" value="12.2"
tModel="myLatLong.long">
<keyedReference name="random" value="1000"
tModel="myLatLong.altitudeInMetres">
</keyedReferenceGroup>
This is convenient, and yes, you can do the same thing in the property
approach, but it's less obvious how you distinguish between a "point" and a
"3Dpoint" when using the property approach.
Tony Rogers
Computer Associates
-----Original Message----- From: Tong Jin
[mailto:tong_jin@bah.com] Sent: Thu 03-Mar-05 3:06 To:
John Colgrave; Von Riegen, Claus Cc: Brown Chris;
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
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
--------------------------------------------------------------------- To
unsubscribe, e-mail: uddi-spec-unsubscribe@lists.oasis-open.org For
additional commands, e-mail:
uddi-spec-help@lists.oasis-open.org
|