uddi-spec message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [uddi-spec] Ready for Vote: RE: [uddi-spec] Groups - uddi-spec-tc-tn-understandingkeypartitions-20060502.doc (uddi-spec-tc-tn-understandingkeypartitions-20060822.doc) modified
- From: Paul Denning <pauld@mitre.org>
- To: "Luc Clement" <luc.clement@systinet.com>, <uddi-spec@lists.oasis-open.org>
- Date: Wed, 13 Sep 2006 16:01:21 -0400
You should change EAN to GS1 in a few more places.
Also
[1]
http://www.oasis-open.org/committees/document.php?document_id=20278
[1] is a little wierd in that the href is to the documented dated
20060822, but the text on the page shows 20060502
Why is it not 20060913?
Somewhere you should state that well-known taxonomies or
classification/identifier systems SHOULD use the same well-known
tModelKey in every registry.
If GLN is well-known, then the Example1 registry should have used the
well-known key, which presumably is not the registry assigned key
DEF. Registry admin are likely to be the owners of these tModels
since private registries usually will not have publishers who
authoritatively represent the organization that defined the well-known
taxonomy. In this example, someone from gs1.org may not be a
publisher to the Example 1 private registry.
You may want to say that although there is no standard API for it, UDDI
implementations SHOULD have a way to change entity keys. For
example, to change the registry-defined key "DEF" to the
well-known key. There is probably other details to consider, such
as, identiferBags that have used "DEF" should be changed to use
the well-known key. Probably don't want to get into the isReplaceBy
stuff.
Something for further discussion:
If for some reason the Example 1 registry needed to keep the key
"DEF" for GLN, it may be a good idea to added an entry to the
identifierBag of the "DEF" tModel. The keyValue would be
the (well-known) tModelKey for that taxonomy in the National Service
Registry (in the example), but what tModelKey should be used to identify
this identifier system. That is, how do you identify the National
Service Registry. What if in a 3rd registry that same taxonomy is
identified by a third tModelKey? I may want to add another
keyedReference to the DEF tModel identifierBag whose keyValue is the
tModelKey for the taxonomy used in this 3rd registry.
Seems like you can define a tModel, which is an identifier system and
have it refer to a particular registry. The value set for this
identifier system would be unchecked, but would consist of the keys
published in that registry.
Taking it a step further, I can use this tModelKey in the technical
fingerprint of a bindingTemplate that contains the accessPoint to that
registry.
This may be useful for large enterprises (U.S. DoD, U.S. gov) that may
have many UDDI registries, and you need to be able to register the
registries. You need to identify the registries somehow, as well
as, provide accessPoints to the inquiry interfaces for each
registry.
You would want to search UDDI for all tModels that refer to identifier
systems that are UDDI registries. You can find_tModel for identifer
systems, but there should be another well-known taxonomy to categorize it
as a "UDDI registry tModel".
Note that the well-known tModelKey
"uddi:uddi.org:categorization:nodes" is not quite right as
currently defined. It is intended for multi-node registries.
"This checked category system is only permitted to be used by the
node itself. ... This checking guarantees the ability to query a single
node and determine all the nodes that participate in a given
registry."
Perhaps we define a tModel
uddi:uddi.org:categorization:registries with a single valid value
"registry". Anyone would be able to publish a tModel that
uses this in the categoryBag; it would not be limited to use by the
registry itself.
Paul
At 02:44 PM 2006-09-13, Luc Clement wrote:
We reviewed the TN
during this week's telecon. The updates have now been posted to the
following location.
http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-understandingkeypartitions-20060822.htm
http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-understandingkeypartitions.htm
http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-understandingkeypartitions-20060822.pdf
We will be voting to
approve this TN at the next telecon on 3 Oct
-- Luc
Luc
Clément
| Director, Product
Management | Systinet, a Mercury Division |
Co-Chair, OASIS UDDI
Technical Committee
One van de Graaff Drive Burlington, MA 01803
Phone +1 781.362.1330 | Mobile +1 978.793.2162 | Fax +1 781.362.1400
|
-----Original Message-----
From: luc.clement@systinet.com
[
mailto:luc.clement@systinet.com]
Sent: Wednesday, September 13, 2006 14:09
To: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] Groups -
uddi-spec-tc-tn-understandingkeypartitions-20060502.doc
(uddi-spec-tc-tn-understandingkeypartitions-20060822.doc)
modified
Information about the document named
uddi-spec-tc-tn-understandingkeypartitions-20060502.doc
(uddi-spec-tc-tn-understandingkeypartitions-20060822.doc) has been
modified by Luc Clement.
Document Description:
Final edit. Ready for vote
View Document Details:
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/document.php?document_id=20278
Download Document:
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/20278/uddi-spec-tc-tn-understandingkeypartitions-20060822.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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]