RE: [uddi-spec] Groups - Property Support in UDDI(uddi-spec-tc-prop030-property-and-significant-keyname-20050225.doc) uploaded

Title: RE: [uddi-spec] Groups - Property Support in UDDI (uddi-spec-tc-prop030-property-and-significant-keyname-20050225.doc) uploaded

TC,

 

I suspect the proposed datatyping is 
too limited to bring considerable benefits. 

 

Please correct me if I'm wrong.

 

Cheers,

Max

 

 

From: Rogers, Tony [mailto:] 

Sent: Thursday, 3 March 2005 05:38
To: Tong Jin; 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

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: