Re: [uddi-spec] keyNames and keyValues for categories

["Anne Thomas Manes" <anne@manes.net>]

I agree with Claus that Option ii) is the most appropriate one. Option iii)
would only work if you use the uddi:general_keywords taxonomy. I see two
significant problems with Option 1): it would require changes to the UDDI
data structure and APIs (meaning it couldn't be added to the UDDI spec until
V4), and it's redundant, since we already have support for name/value pairs
via custom taxonomies.

In any case, I encourage the grid forum to define a set of custom taxonomies
to represent this information.

We've been talking about defining a process to register "standard"
taxonomies -- those developed by industry groups, standards bodies, and
other organizations -- perhaps in the public registry (although I'm still
not sure how we indicate that the taxonomies have passed through this
process and have achieved some type of formal endorsement). This would
provide us with an excellent pilot project to define and test this process.

Anne


----- Original Message -----
From: "Von Riegen, Claus" <claus.von.riegen@sap.com>
To: "'Matthew J. Dovey'" <matthew.dovey@oucs.ox.ac.uk>;
<uddi-spec@lists.oasis-open.org>
Sent: Thursday, July 17, 2003 9:14 AM
Subject: RE: [uddi-spec] keyNames and keyValues for categories


> Matthew,
>
> Option ii), that is, mapping key/value pairs to tModelKey/keyValue pairs
is the most appropriate one. It is strongly typed, programmatically
supported in the Inquiry API (keyNames are not significant in find_xx API
calls for arbitrary tModels), and can be extended with validation services
(if, for example, only certain CPU types are allowed).
>
> Option iii) does not work since you usually can not search based on
keyNames. You can do that if you use the uddi-org:general_keywords category
system - this would map key/value pairs to keyName/keyValue pairs. But you
are not able to add validation services to general_keywords.
>
> Adding new structures as in i) would be least appropriate since it is not
standardized.
>
> Is there a reason why you fear to add a large amount of tModels?
>
> Claus
>
> -----Original Message-----
> From: Matthew J. Dovey [mailto:matthew.dovey@oucs.ox.ac.uk]
> Sent: Donnerstag, 17. Juli 2003 14:49
> To: uddi-spec@lists.oasis-open.org
> Subject: [uddi-spec] keyNames and keyValues for categories
>
>
> In reviewing the GRID requirements can I just check something as to how
> categories work.
>
> My understanding is that the value of the keyName in the keyedReference
> is intrinsically linked to to the keyValue, i.e. it provides a human
> readable name for that value.
>
> I ask because one GRID implementation of UDDI which adds an extensions
> requires key/value pairs to expose GRIDService data, and I'm wondering
> if this can be slotted into the existing UDDI structures or whether this
> might require something new.
>
> Essentially, the sort of information that would be useful to add to a
> GRID service/resource would be information such as CPU type, CPU speed,
> no. of processors, available memory, available disk etc.
>
> There are three ways to do this as far as I can see -
>
> i) Add a new structure for key/value pair type data.
> ii) use categories as is - this would imply in the above case new
> tModels for CPU type, CPU speed, memory etc. this could lead to a large
> amount of tModels!
> iii) Allow key/value pairs in keyedReferences i.e. we could have
> something like:
>
> <keyedReference tModelKey="grid:serviceData" keyName="CPU Type"
> keyValue="Intel 586" />
> <keyedReference tModelKey="grid:serviceData" keyName="CPU Speed"
> keyValue="2GHz" />
> <keyedReference tModelKey="grid:serviceData" keyName="Processors"
> keyValue="64" />
> <keyedReference tModelKey="grid:serviceData" keyName="Memory"
> keyValue="4GB" />
> <keyedReference tModelKey="grid:serviceData" keyName="Disk"
> keyValue="3TB" />
>
> Option 3 seems the neatest to me - but is this breaking the
> keyedReference semantics in a direction that people don't want to go in?
> Is there something nasty in this approach which I'm not seeing?
>
> Matthew
>
>
> You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgro
up.php
>
> You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgro
up.php
>