[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] CR32
[LC] Inline - I think we're real close but there is still
an open issue. Please see
below.
Luc From: John Colgrave [mailto:colgrave@hursley.ibm.com] Sent: Friday, June 13, 2003 03:55 To: Luc Clement Cc: uddi-spec@lists.oasis-open.org Subject: 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. [LC] Agree. To be clear, the intention is to bring forward all V2 tModels and as such 11.1.5 and 11.1.6 stay as do the v2 keys of these new tModels.
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:
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.
[LC] I'm in favour of 3 with modifications made to the v3 spec.
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. [LC] I agree on the last two points that said, some text is needed to be added (along with the categorization you proposed) to the existing 4 value sets (along with that of the TN) to reflect adoption of this new mechanism for mapping keys. 1-2 sentences should suffice; could you please take a stab at this?
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:
[LC] In short, my interpretation was different than yours. I had assumed that you intended to use the categorization as a means for both mapping AND expressing the validation rules; I see from the above that this is not the case. I'm fine with this. This does mean however that the text of the tModels remains normative wrt saves - I'm also fine by this. What I question though is the need to have a value set with more than a single value of "entityKey". The set of values you proposed does not seem necessary if the goal is only to signal the need to perform mapping.
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? Open Issue:
IBM
-----Original
Message-----
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 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 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
-----Original
Message----- 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
-----Original
Message----- John, I think that the CR32 needs to
include information in the solution section As I mentioned offline with you, Luc
had a few concerns with the details of To others - please post if you have
further issues to discuss on CR32. Thanks,
You may leave a Technical Committee
at any time by visiting
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]