RE: [uddi-spec] CR32

Luc,

What I meant by not giving full v3 versions of the v2 tModels is that, for instance, there is no complete description of the V2 owningBusiness tModel in the V3 spec. To be precise, I mean the tModel with V1/V2 key of uuid:4064C064-6D14-4F35-8953-9652106476A9 and an evolved V3 key of uddi:uddi.org:identifier:owningBusiness. There is a full description of the V3 owningBusiness tModel, that is the tModel with a V3 key of uddi:uddi.org:categorization:owningBusiness and a derived V1/V2 key of uuid:D08FFB57-3E4C-3F9B-A9F7-022B7BDB7D4E but that is a different tModel. I think what has happened is that in those cases where we introduced the _v3 version, we just made up some new keys for what was already there, namely the old V2 version, but we did not add the old V2 version as well. If the intention is to describe all of the V2 tModels again in the V3 spec. then we should keep sections 11.1.5 and 11.1.6 and change them to use the keys of the existing V2 tModel and add the new categorization. I will start work on updating CR-032 accordingly.

Moving on to your first concern, believe me I am also concerned at the delay that this is causing to the WSDL TN but I am also keen to solve this problem once, in the right way, as whatever we do some code has to be written. There were three options discussed for how to trigger the mapping of keyValues for a Value Set:

Registry implementers read the V3 spec. and TNs/BPs looking for definitions of Value Sets that have entity keys as valid values and hard-code their registry implementations to do the right thing for just those Value Sets. This approach means that every time another such Value Set is defined, all registry implementations have to change to support it.
We use general_keywords to add some categorization information that tells a registry that this particular Value Set has entity keys as valid values. This allows registry implementations to be written to do the right thing for any such Value Set, whether it is introduced by a future TN/BP or even by an end user defining their own proprietary Value Set.
We use a new canonical tModel to add equivalent categorization information.

Options 2 and 3 are very similar and both allow for a flexible registry implementation that can cope with any future Value Sets that are defined which have entity keys as the valid values. I thought the consensus when this was discussed was to prefer option 3 to option 2 but I could live with option 2, depending on where we end up at the end of this note. I assume we would define a uddi.org namespace to use for this, but that would not have to be done in the V3 spec. itself.

I do not like the idea of not adding any information to the Value Set tModels and relying on registry implementations to “know” which Value Sets need special treatment. I think this would be at least as much work to implement and would mean that the registry implementations would have to be updated every time a new Value Set were defined.

This is not just applicable to the TN, it applies to the four such Value Sets defined in the V3 spec. itself.

There is also a “third way” which is to indicate only that mapping needs to occur and omit the specification of which type(s) of entity key are valid, but I am not sure whether this alone would address any of your concerns.

I will move on to address your second concern.

My intentions were to:

indicate that the valid values of a Value Set were entity keys and would therefore have to be mapped (wherever/whenever necessary); depending on implementation some action may have to be taken on a save as well; this is really just a binary indicator of whether mapping is required for a Value Set or not
indicate if only one specific type of entity key is valid; this is partly a performance hint to save registry implementations checking all different entity types to see if a supplied key is valid

I think our interpretations are subtly different, and would not presume to say which one is correct, so I will try and address your other points:

1. If we go for option 2 or three above then it would be an error for any of the canonical tModels that have entity keys as valid values not to have the categorization that indicated that. If we went for option 2 or three and the categorization were not there then no mapping would be done and the wrong information would be returned. To do the mapping anyway would be the worst option of all as far as implementations were concerned as they would have to know about all the canonical tModels and apply the mapping regardless, but also be written to support other tModels that had the categorization.

2. No, the categorization should support the specified behaviour of isReplacedBy etc. Where there is only ever one type of entity key allowed, with owningBusiness for example, there is no difference between the categorization and the specified behaviour. For something like isReplacedBy it is more complicated as the valid values are either tModelKeys or businessKeys. In this case, the categorization would have to say that any entityKey was valid and registry implementations would still have to do the extra checking in this particular case. I did mention the option of having multiple keyedReferences in this case, one specifying tModelKey and another specifying businessKey, but there was not a great deal of enthusiasm for that approach, and even with that the “rule” that when isReplacedBy is used in a tModel that the entity key must be that of another tModel, and similarly for businessEntity, would have to be “just known”, it could not be expressed by the categorization.

3. I don’t see the contradiction. Any Value Set that takes an entity key as a valid value should indicate if only one particular type of key should be used, or any entity key can be used. For example, the description of the valid values of owningBusiness_v3 begins with “The value set of this value set is the set of businessKeys. The content of a keyValue in keyedReferences that refers to this tModel must be a version 3 format businessKey.” and includes “the referred-to businessEntity must exist”. If we remove “version 3 format” then the intent of the rest of the text would be expressed exactly by categorizing the owningBusiness tModel with an entityKeyValues value of “businessKey” I think the difference between our views of this is that I see mapping as something that could happen during the save as well, which is why knowing the type of key expected could be an optimization, as I mentioned above. There is certainly an aspect of validation here, but I do not see that as something contradictory to mapping, I see it as a part of mapping.

4. No, it applies to Value Set tModels, both identification schemes and categorization schemes/systems. I tried to be consistent in the use of Value Set as I believe that is the correct term to encompass both.

5. If you accept that mapping is something that relates to saving as well as retrieving then a Value Set that declares that it has entity keys as valid values is implicitly checked as the mapping (during the save) would fail if the entity key were not valid. If you see mapping as something that only happens when retrieving information then you could save a keyedReference with an invalid entity key and not find out about it until it was retrieved. I think that the very idea of an entity key as a valid value implies that the value is checked, regardless of whether or not the tModel includes the checked keyedReference. I cannot see how to handle an invalid keyValue if we leave that until a find/get is done. I will add some words to the Design Goals to say that the use of entityKeyValues implies checked behaviour.

6. Given that the valid values are entity keys then I do not see how this could be externally validated as the set of valid values depends on the content of the registry at the time of the save and I doubt that an external validation service would know the set of valid businessKeys at any point in time in a particular registry for example. The words I shall add to the Design Section will say that the use of entityKeyValues implies internal checked behaviour.

I can see that some of these issues relate to the extensible nature of having explicit categorization to indicate that entity keys can be valid values, but some of them relate to the existing Value Sets so I think that it should be fairly easy to address the extensibility concerns which will leave us with a much better approach at very little (if any) additional implementation cost.

Assuming that I change section 4.1 in the CR to update the descriptions of the tModels in the V3 spec. with the new categorization, remove the latter part of 4.3 in the CR concerning 10.5.1-10.5.4 and add a paragraph to the Design Goals of the new tModel to say that usage of the tModel implies internal checked behaviour, would that address your concerns?

John Colgrave

IBM

-----Original Message-----
From: Luc Clement [mailto:lclement@windows.microsoft.com]
Sent: 12 June 2003 23:21
To: John Colgrave; Tom Bellwood; John Colgrave
Cc: uddi-spec@lists.oasis-open.org
Subject: 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

uddi-spec message