Title: RE: [uddi-spec] Groups - Property Support in UDDI (uddi-spec-tc-prop030-property-and-significant-keyname-20050225.doc) uploaded
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:]
Sent: Thu 03-Mar-05 3:06
To:
John Colgrave; Von Riegen, Claus
Cc: Brown Chris;
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 || 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:
---------------------------------------------------------------------
To
unsubscribe, e-mail:
For
additional commands, e-mail:
