RE: [uddi-spec] Groups - uddi-spec-tc-cr053-keyGeneratorCategorizationRestrictions-20040126.doc uploaded

["John Colgrave" <colgrave@hursley.ibm.com>]

First of all, I think the description of the UDDI Types Category System is
not very clear and we should look at improving it in a future specification.

With regard to this particular issue, reading the Introduction and the
Design Goals I got the impression that the entire Category System only
applied to the categorization of tModels, but this is not the case.

However, the keyGenerator ID is described as having the tModel ID as its
parent and the description of the tModel ID includes the sentence "This key
is the root of the branch of the category system that is intended for use in
categorization of tModels within the UDDI registry."

The description of keyGenerator says "Marking a tModel with this
categorization..." and there is no description of a meaning for any other
type of UDDI entity.

I think the intention of the spec. is clear but if the wording needs to be
strengthened to address Claus's point B then I think we should do either
what Luc suggests and strengthen the wording of just keyGenerator, or
strengthen the wording of the tModel ID and restrict the entire branch to
tModels only.

I am not sure about point A.  There seem to be several separate cases here:
1) saving a new keygenerator tModel; 2) removing the categorization from an
existing keyGenerator tModel; 3) updating an existing (non-keygenerator)
tModel with the categorization.  There are also both V2 and V3 APIs to
consider.

I am not sure why we would restrict creation of keyGenerator tModels to the
V3 API only given that the V3 API allows a keyGenerator tModel to be created
without a publisher assigned key.  Obviously, the concept of a keyGenerator
tModel is inherently a V3 concept, but I see no reason why a V2 save_tModel
with the right categorization could not be treated in much the same way as a
V3 save_tModel without a publisher assigned key.  This would avoid extra
code in the V2 API support that would be there just to restrict something
that could work.

I think that the case of saving a new keyGenerator tModel using the V3 API
is adequately described at the moment.

I am assuming that removing the categorization should not be allowed, rather
than just "demoting" the tModel to an ordinary, non-keygenerator, tModel.  I
think that the case of removing the categorization from an existing
keyGenerator tModel using the V3 API requires a change to 5.2.18.3 or
5.2.18.3.1, along the lines of the last part of Claus's suggested change to
5.2.18.3, although I am not sure that E_valueNotAllowed is the correct error
to use given that the problem is the absence of a keyedReference.  The same
thing applies to the V2 API.

I think that the case of adding the categorization to an existing,
non-keygenerator, tModel could be handled by returning E_valueNotAllowed,
both from the V3 API and the V2 API.

I think it might be useful to separate more clearly the description of the
"create" case from the description of the "update" case.

John Colgrave
IBM


> -----Original Message-----
> From: Luc Clément [mailto:luc@iclement.net]
> Sent: 26 January 2004 17:51
> To: claus.von.riegen@sap.com; uddi-spec@lists.oasis-open.org
> Subject: RE: [uddi-spec] Groups - uddi-spec-tc-cr053-
> keyGeneratorCategorizationRestrictions-20040126.doc uploaded
> 
> Claus,
> 
> I agree with the intent of the CR but would like to offer the following
> editorial comment wrt the proposed update to the save_binding,
> save_business
> and save_service sections.
> 
> For purpose of consistency how we've dealt with this type of exception in
> the spec, I'd rather that we not add any mention wrt restricting the use
> of
> the keyGenerator categorization in these sections, but rather opt to state
> its allowable usage in the description of keyGenerator value in section
> 11.1.1.4. Valid Values (of the UDDI Types Category System - [1]).
> 
> Luc
> 
> [1] http://uddi.org/pubs/uddi_v3.htm#UDDITypes
> 
> 
> -----Original Message-----
> From: claus.von.riegen@sap.com [mailto:claus.von.riegen@sap.com]
> Sent: Monday, January 26, 2004 05:06
> To: uddi-spec@lists.oasis-open.org
> Subject: [uddi-spec] Groups -
> uddi-spec-tc-cr053-keyGeneratorCategorizationRestrictions-20040126.doc
> uploaded
> 
> The document
> uddi-spec-tc-cr053-keyGeneratorCategorizationRestrictions-20040126.doc has
> been submitted by Claus von Riegen (claus.von.riegen@sap.com) to the OASIS
> UDDI Specification TC document repository.
> 
> Document Description:
> Please find attached a proposed V3 spec change request that clarifies the
> usage of keyGenerator categorizations.  Thanks,  Claus
> 
> Download Document:
> http://www.oasis-open.org/apps/org/workgroup/uddi-
> spec/download.php/5156/udd
> i-spec-tc-cr053-keyGeneratorCategorizationRestrictions-20040126.doc
> 
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/uddi-
> spec/document.php?document
> _id=5156
> 
> 
> 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.
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of
> the
> OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/uddi-
> spec/members/leave_workgro
> up.php.
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/uddi-
> spec/members/leave_workgroup.php.