OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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

You should change EAN to GS1 in a few more places.


[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.


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.
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-20060822.doc) has been modified by Luc Clement.

Document Description:
Final edit. Ready for vote

View Document Details:

Download Document:

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]