RE: [uddi-spec] CR32

["Luc Clement" <lclement@windows.microsoft.com>]

Title: RE: [uddi-spec] CR32

Thanks to Tom for egging me on and paraphrasing my concerns over dropping section 11.1.5 and 11.1.6 and the issues with the table at 10.1.4. I have no problems with that part of the CR. To be clear, we need to preserve the definition of the v2 owningBusiness and isReplacedBy tModels and evolve their keys rather than deriving them.

John, you state in your note that “we do not give full v3 versions of the v2 tModels in the v3 spec”; that’s not correct. Indeed, the v3 spec does include full v3 version of the v2 tModels that have been brought forward in v3 – that's why we have a set of exceptions identified at 10.1.4. We need to keep these two tModels in the v3 spec, otherwise, they aren’t part of the normative spec. Do note that some of the v2 tModels did not make their way to v3 (e.g. NAICS) and rather where delegated to the UBR operators to manage and publish (and yes those involved will be doing this…).

You are correct wrt the error to return, it should be E_invalidValue so that we are consistent with the use of error codes.

Now for my concerns:

a. Delay Incurred by the WSDL v2 TN
I’m concerned that the WSDL v2 TN is getting delayed by this CR which is attempting to 1) correct a problem in the spec wrt the need to perform mapping on finds and gets and 2) the desire to add a new normative tModel to address a perceived hole in the v3 spec as it relates to the inability to define a) when mapping occurs and b) how to enforce the entity key type applicable in a keyedReference in a save operation.

I think that the TN only needs the former, and if I’m correct, then we should split the CR in two allowing us to accept what is absolutely necessary for the TN as soon as possible, and giving us the time to fully consider the impact of the latter (the new  tModel). Am I correct in stating that the TN only really needs the former?

b. entityKeyValues Category System
As is, the tModel is not sufficiently specified IMO to be considered a normative part of the spec; if it is to be added to the spec – something that I’m not absolutely against but quite frankly don’t think meets the bar we set out for ourselves – then we need to cover node behaviour end-to-end.

The “Design Goals” states:

By Categorizing a Value Set with this tModel the publisher of the Value Set indicates that entity keys, either of one particular type or entity keys in general, form the valid values of the Value Set.  This allows a UDDI implementation to map entity keys between versions as is done with all other uses of entity keys.

This is unclear. I think what your intention is to define a tModel that has two separate but related functions: a) when mapping occurs and b) how to enforce the entity key type applicable in a keyedReference in a save operation. For a) this mapping would be used for finds and gets as an indication that the server MUST (presumably) perform mapping. For b) the server MUST validate the set of keys used enforcing that the key used satisfies what is allowed by the entityKeyValues categorization. Is this interpretation correct? If so, this needs to be clarified in the text as I don't think it reads this way.

Presuming that my interpretation is correct:

1. What is the normative server behaviour wrt mapping of keys on finds and gets if either of the isReplacedBy, owningBusiness (etc) tModels are not categorized with the entityKeyValues tModel? Presumably, mapping would be required regardless.

2. In the case of the isReplacedBy, owningBusiness (etc) tModels, does the behaviour specified by the categorization override the spec’ed behaviour of the isReplacedBy, etc tModels? Do we also need to update the isReplacedBy (etc) tModels descriptions explaining that key usage behaviour is controlled by the entityKeyValues tModel?

3. In section 4.3 of the CR, the text suggests that the use of the tModel is only for the purpose of mapping of keys (belonging to different keying schemes). This seems to contradict the use of this tModel as the means of enforcing the type of entity key that can be used to point to another as part of save operations. I fear I may have misunderstood your intention wrt “save” behaviour.

4. Is the entityKeyValues tModel only applicable to “categorization” tModels? I think the text needs to state something about this and specifically call out that it only has meaning or is only enforced by a server if it is used in conjunction with a categorization tModel

5. what is the behaviour of a node when the entityKeyValues tModel is used with a non-checked categorization tModel? Presumably, mapping of the keys will continue to occur on finds and gets (otherwise we break clients), but save operations may/may not/must not/should not (?) validate the set of keys specified against the set of valid values specified on the tModel.

6. in the presence of externally checked tModels, what is the behaviour of an external value set service? Does it need to perform this validation on saves? I'm not entirely clear how this would work.

As I write this, I fear that I’ve terribly misunderstood the intent of the entityKeyValues tModels as it relates to saves. Could you please clarify?

Again, if at all possible, then I think we should split this CR in two so as to allow the WSDL TN to progress forward.

Luc Clément
Microsoft

 

-----Original Message-----
From: John Colgrave [mailto:colgrave@hursley.ibm.com]
Sent: Thursday, June 12, 2003 02:29
To: 'Tom Bellwood'; 'John Colgrave'
Cc: uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] CR32

Tom,

The V2 tModels already have V3 keys.  The addition of the new categorization is covered by section 4.3 in the CR, relating to new sections 10.5.1-4 as you mention.  We don't give full V3 versions of the V2 tModels in the V3 spec. so I just described the delta.

As for updating the CR, I did that and uploaded the new CR on May 28th.  See http://lists.oasis-open.org/archives/uddi-spec/200305/msg00113.html

I think the minutes are incorrect with respect to the error code to be returned.  My notes from the last call were to use E_invalidValue but the minutes say E_invalidKey should be returned.

John Colgrave
IBM

-----Original Message-----
From: Tom Bellwood [mailto:bellwood@us.ibm.com]
Sent: 11 June 2003 23:26
To: John Colgrave
Cc: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] CR32

John,

I think that the CR32 needs to include information in the solution section
which ports forward the V2 versions of the removed tModels and decorates
them with V3 evolved keys.   We can't just remove sections 11.1.4 and
11.1.5 can we?  We still have tModels for owningBusiness and isReplacedBy
and need to document them there I think.  Unless I'm missing something,
they just need to have evolved V3 keys, together with their current V2
versions, drop the "_V3" from their names, and add the categorizations you
currently describe in the CR pertaining to sections 10.5.1-4.   You may
also recall that from the last telecon, you agreed to update the CR to
indicate that there is no ordering dependency on what checks are done in
what order.   If I wasn't so delinquent in posting minutes that might have
been clearer - sorry.

As I mentioned offline with you, Luc had a few concerns with the details of
the CR.  I'm not sure whether the above addresses his concerns, but I'm
sure he'll post if there are others.   It certainly doesn't address the
opinion he raised at the last telecon that the new tModel could be hard to
consider as an errata.   I still believe as Claus noted during the telecon
though that we need a complete solution that doesn't put a burden on users,
or else we risk hurting adoption.  I think what you've got fits that bill.

To others - please post if you have further issues to discuss on CR32.
We'd like to have a ballot and get this CR disposed so that we can move
forward with the WSDL-TN.   My apologies for posting late on this as well,
as I've been out of the office for a couple weeks.

Thanks,
Tom Bellwood       Phone:  (512) 838-9957 (external);   TL:  678/9957
(internal)
Co-Chair, OASIS UDDI Specification TC

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_workgroup.php