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: Proposed Typo and Clarifications to be added to CR002


Dear TC,
 
Members of our v3 implementation team have identified a number of errors or ambiguities in the v3 spec. I've shared  these already with Tom and Claus. Please find below a description of the issues and proposed resolution.
 
For discussion on Tuesday's call.
 
Luc

Luc Clément
Microsoft
Co-chair, OASIS UDDI Spec TC

 

1       Typo in uddi:uddi.org:categorization:nodes

There is a typo in "uddi:uddi.org:categorization:nodes" of section 11.1.3.3. This section states: 

11.1.3.3 tModel Definition

Name:                          uddi-org:nodes

Description:                 Category system for identifying nodes of a registry

UDDI Key (V3):              uddi:uddi.org:catgorization:nodes

Evolved V1, V2 format key: uuid:327A56F0-3299-4461-BC23-5CD513E95C55

 

Changes necessary: change the v3 UDDI Key value to "uddi:uddi.org:categorization:nodes"

 

Proposed action: add to CR002 omnibus Change Request.

2       Section 1.8.4, footnote reference error

Footnote [3] should refer to "Appendix D" not "Appendix E".  

 

Proposed action: add to CR002 omnibus Change Request.

3       Section 1.8.2 - Timezone

"Section 1.8.2 talks about a "new feature" of tracking a contacts timezone in their address. There aren't any specific changes to the address element that I can see to support this, so I was assuming this reference to timezone would be a "best practice" kind of thing where you would add the timezone as an address line.  Section D.3 makes no recommendations on how to do this. 

 

I think either 1.8.2 should be struck, or Section D.3 should make some specific recommendations on how to do timezone." 

<CvR>The approach described in 1.8.2 can be carried out in V2. What was actually meant here is the Postal Address tModel we developed for use in the UBR. However, this is not published yet and I believe that removing 1.8.2 does the job.</CvR> 

 

Proposed action: add to CR002 omnibus Change Request. Please note that UBR Operators are in the process of updating the UBR tModels where this description will be added.

4      Section 5.4.1.1 - Ambiguous text

Section 5.4.1.1 states:

5.4.1.1 Intra-Node Ownership Transfer

Intra-node ownership transfer involves transferring entity ownership from one publisher to another within the same UDDI node.  Usage scenarios for this type of transfer include the following:

·         Businesses or organizational merges:  Multiple organizations need to be consolidated under the control of a single publisher.

·         Domain key generators: One use of ownership transfer is the transfer of ownership of a derived keyGenerator from one publisher to another to enable her or him to publish entities using keys in that domain.

 

In conjunction with ownership transfer, the save_service API can be used to move services (and binding templates) between one business entity and another as described in Section 5.2.17.3 Behavior of the save_service API. Using the save_service call it is possible to move an existing businessService element from one businessEntity to another by simply specifying a different parent businessEntity relationship. Changing a parent relationship in this way causes two businessEntity structures to be changed. Doing so enables the following scenarios:

·         Divestitures: An organization needs to reassign the control of a set of services to two or more publishers.

·         Consolidation of registry entities:  There are multiple entities for a given business that are to be consolidated under a single publisher.

 

The text in blue is misleading in that it seems to imply that this type of save_service operation is a transfer of ownership, which it is not.  Both businessEntities, old and new, must be owned by the same publisher.  This is not a change in ownership. It is recommend removing the text in blue and the last bullet of section 5.4.1.1. 

<CvR>Yes, it is misleading. However, I would prefer to have the (blue) section and to clarify things by saying that (compared to ownership transfer) the save_xx APIs can be used to move entities between parent entities that are owned by the same publisher.</CvR>

 

Proposed action: add to CR002 omnibus Change Request.

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]