[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] CR32
Luc,
You said in a previous note that you would prefer not to specify “what gets mapped to what” – if you really want to fully express the rules for things like isReplacedBy then that goes beyond what was envisaged for the proposed Category System so we will have to invent a way of doing that. Of the top of my head, categoryGroups would seem to be the way to do it with another Category System to indicate the type of entity in which the use of the Category System such as isReplacedBy occurs. If we call this new CategorySystem entityKeyUsedIn and say that the valid values are “businessEntity”, “tModel” etc. then isReplacedBy would be categorized with the following:
<keyedReferenceGroup tModelKey=”The key of a third tModel to model the group”> <keyedReference tModelKey=”uddi:uddi.org:categorization:entitykeyusedin” keyValue=”businessEntity”/> <keyedReference tModelKey=”uddi:uddi.org:categorization:entitykeyvalues” keyValue=”businessKey”/> </keyedReferenceGroup> <keyedReferenceGroup tModelKey=”The key of a third tModel to model the group”> <keyedReference tModelKey=”uddi:uddi.org:categorization:entitykeyusedin” keyValue=”tModel”/> <keyedReference tModelKey=”uddi:uddi.org:categorization:entitykeyvalues” keyValue=”tModelKey”/> </keyedReferenceGroup>
This categorization says that if a businessEntity includes isReplacedBy in its categoryBag then the valid values are only businessEntity keys, and similarly if a tModel includes isReplacedBy in its categoryBag then the valid values are only tModelKeys.
For something like owningBusiness I suggest we keep the approach currently in the CR so that a single use of entityKeyValues means that wherever owningBusiness is used the valid values are always only business keys. In general I would say that a use of entityKeyValues outside of a group like this is the equivalent of a wildcard for entityKeyUsedIn. I guess this could be combined with the group if people want to get really fancy.
John Colgrave IBM
-----Original Message-----
John,
I would prefer catering to the second (i.e. 2.) to remove as much "majic" as possible and to provide as a consequence more consistency wrt implementation. Can we try to close on 1 vs 2 during tomorrow's call?
Luc
From: John Colgrave
[mailto:colgrave@hursley.ibm.com] Luc,
To be clear about your clarification, sections 11.1.5 and 11.1.6 will not contain new tModels, but V3 versions of the existing V2 tModels, and their V2 keys will change to match the current V2 tModels, as will their names. Section 11.1.5.2 will become:
Name: uddi-org:owningBusiness Description: Category system used to point to the businessEntity associated with the publisher of the tModel UDDI Key (V3): uddi:uddi.org:categorization:owningBusiness Evolved V1,V2 format key: uuid:4064c064-6d14-4f35-8953-9652106476a9 Categorization: categorization Checked: Yes (valid values are entity keys)
I assume that the entry in the table in section 10.1.4 for owningBusiness should be changed to show a V3 key of uddi:uddi.org:categorization:owningBusiness rather than the current key which is an identifier rather than a categorization.
Section 11.1.6.2 will become:
Name: uddi-org:isReplacedBy Description: An identifier system used to point to the entity, using UDDI keys, that is the logical replacement for the one in which isReplacedBy is used. UDDI Key (V3): uddi:uddi.org:identifier:isReplacedBy Evolved V1, V2 format key: uuid:e59ae320-77a5-11d5-b898-0004ac49cc1e Categorization: identifier Checked: Yes (valid values are entity keys)
I lost track of the discussion of isReplacedBy and its cardinality etc. so I am just assuming a straightforward update of what is currently in the V3 spec.
Given that we are going to give the complete V3 definitions of owningBusiness and isReplacedBy, including the new entityKeyValues categorization I don’t think an extra reminder in Chapter 10 is required.
I think everyone is in agreement that we will use a new categorization tModel to indicate that another Value Set (either Category System or Identifier System) uses entity keys as its valid values.
I think you are right that there is still one open issue and I don’t think we are yet on the same page regarding it. I gave two intentions for it which I would have thought corresponded to your assumption but you say that you see from my two intentions that this is not the case.
There seem to be two types of rule regarding the types of entity key that can be used: 1. An unconditional one such as owningBusiness where no matter how/where it is used the valid values are always business keys. 2. A conditional one such as isReplacedBy where if a tModel includes a keyedReference referencing the identifier system then the valid values are tModel keys whereas if a businessEntity includes a keyedReference referencing the identifier system then the valid values are business keys
My original suggestion was to cater for the first of these types of rule by specifying a single entity key type as the value of the entityKeyValues categorization.
I was not planning to directly support the second of these types of rule which is why there is a generic entityKey value for the entityKeyValues categorization. Note that in this case some “magic” is still required on the part of the registry implementation. We could remove the entityKey value and require multiple keyedReferences, one for each valid type of entity key, but as I mentioned this was discussed on a call and there did not seem to be any support for doing that. I would be quite happy to go with that approach but even with that there would still be the same amount of residual “magic” required if the valid values depend on the type of entity using a particular Value Set.
John Colgrave IBM
-----Original Message-----
[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] 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: 1. 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. 2. 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. 3. 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.
[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: 1. 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 2. 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
[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]