OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [uddi-spec] CR32


Title: RE: [uddi-spec] CR32
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]
Sent: Monday, June 16, 2003 06:47
To: Luc Clement
Cc: uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] CR32

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-----
From: Luc Clement [mailto:lclement@windows.microsoft.com]
Sent: 15 June 2003 07:59
To: John Colgrave
Cc: uddi-spec@lists.oasis-open.org
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:

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.
[LC] OK, I agree that mapping should only occur in the presence of categorization - this simplifies code which is a good thing. The implication of this though is that section 10 needs to be updated to remind implementors that migration of v2 nodes requires that these tModels need to be upgraded with this new 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.
[LC] Per my note above, if indeed we are going to only use a single categorization, then we only need a single value in the value set of value "entityKey". The set of valid values you proposed should be updated to hold a single value..... UNLESS we want to be able to specify "what gets mapped to what", in which case we'd need the full set of values you proposed as well as adding two categoization in the case of the isReplacedBy. I would prefer that we don't use this as a mechanism to specify what gets mapped to what.

 

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.
[LC]  I'm fine with idea of mapping on a save as an optimization if an implementation wants to take advantage of this. That said, when you state "knowing the type of key expected" this suggests to me that we would need to add a categorization for every type of key (along with an expanded value set). Based on this, I think that the open issue here is that we need to decide if this tmodel is to be used to indicate "what gets mapped to what" or just that mapping occurs. If we choose in favour of the former, then we'll need to add two categorization in the case of isReplacedBy for example.

 

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.
[LC] OK 

 

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.
[LC] Thanks - this is what I was looking for

 

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.
[LC] Thanks - this is what I was looking for 

 

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?
[LC] 

Open Issue:

As as said above, I sense that we have an open issue of whether "what gets mapped to what" or "mapping occurs". I think we need to address this. \

 

I propose and prefer the following:

a. we use the tModel as an indication that "mapping occurs"

b. we use as single categorization within the case where more than one key gets mapped (e.g. isReplacedBy)

c. we reduce to a single value the entityKeyValues value set. This value would be "entityKey"

The alternative being:

a. we use the tModel as an indication of "what gets mapped to what"

b. we use as a categorization for each of the key being mapped (e.g. isReplacedBy)

c. we keep the set of values you proposed for this value set (i.e. entityKey, businessKey, ....) 

 

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

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]