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: AW: [uddi-spec] FW: UDDI cr082 - Duplicative keyedReference in bags

Title: Nachricht
It was not the intention to cover multiple instances of keyed entities with the same key. This has particularly been addressed in section on save_service (UDDI 3.0.1), which states

If the same businessService is contained in more than one businessService argument, the final relationship to the containing businessEntity is determined by processing order - which is determined by first to last order of the information passed in the request. Analogously, if the same bindingTemplate is specified in the call as being in more than one businessService, the businessService that is its container at the conclusion of the call is last one listed.

(I am wondering on why an analogous section has not been added to the save_binding, save_business, or save_tModel API call documentations, but this is not the problem at hand)
I am not sure if this really conflicts with the statement that was added by CR-082. Certainly, a clarification along the lines "It is a requirement not to de-duplicate elements of a sequence, other than for keyed entities as described in section save_service" may help. Are we able to clarify this even after the public review?
  -----Ursprüngliche Nachricht-----
Von: Rogers, Tony [mailto:Tony.Rogers@ca.com]
Gesendet: Montag, 22. November 2004 23:06
An: Luc Clement; uddi-spec@lists.oasis-open.org
Betreff: RE: [uddi-spec] FW: UDDI cr082 - Duplicative keyedReference in bags

Claus is quite correct: we did agree to enlarging the scope of this change request to cover duplicates pretty much everywhere. And yes, that would include duplicate businessService entries in a businessEntity. The same rationale applies: not doing so will break digital signatures. However, then we must face the "interesting" problem of handling the case where the duplicative entries are different - we know that the last one overrides the previous one, but do we preserve the earlier one in its place? If not, how do we avoid breaking the signature? This problem does not occur with keyed references because they are not keyed entities (that statement amuses me, perversely).
My take is that a business entity containing a list of business services with duplicates (especially duplicates with differences) is pretty much broken anyway, so we should feel free to de-dup the service list.
So how do we change the CR to reflect that it does not apply to lists of keyed entities?
-----Original Message-----
From: Luc Clement [mailto:luc.clement@systinet.com]
Sent: Tue 23-Nov-04 7:43
To: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] FW: UDDI cr082 - Duplicative keyedReference in bags

CR-082 has come up in side discussion. I'd like to surface this issue for discussion on Tuesday's meeting when we meet next.
Luc Clément
Senior Program Manager, Systinet
Tel: +1.617.768.4268 / Cell: +1.978.793.2162 /

From: Rob Kochman [mailto:robko@microsoft.com]
Sent: Monday, November 22, 2004 15:30
To: Luc Clement; Von Riegen, Claus
Cc: mirek.novotny@systinet.com; Andrew Hately
Subject: RE: UDDI cr082 - Duplicative keyedReference in bags

We should close on this no later than next Tuesday's meeting.  Luc, can you please add it to the agenda?






From: Luc Clement [mailto:luc.clement@systinet.com]
Sent: Saturday, November 20, 2004 2:11 PM
To: Rob Kochman; 'Von Riegen, Claus'
Cc: mirek.novotny@systinet.com; Andrew Hately
Subject: RE: UDDI cr082 - Duplicative keyedReference in bags


Looping in Andrew.


Claus, I'm not totally happy about the proposed text precisely because it implies specifically what Rob is suggesting. I remember (when working somewhere else) dealing with a CR that stated that the last saved child element of a save would be persisted. I don't think that is what we had in mind when we agree to CR082 originally.


We need to revisit this change to CR-082. Thoughts




From: Rob Kochman [mailto:robko@microsoft.com]
Sent: Saturday, November 20, 2004 16:52
To: Von Riegen, Claus; Luc Clement
Cc: mirek.novotny@systinet.com
Subject: RE: UDDI cr082 - Duplicative keyedReference in bags

Is the intent to allow duplicates in any sequence?  For instance, must duplicate businessService entries be allowed within a businessServices sequence?


From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
Sent: Saturday, November 20, 2004 7:01 AM
To: Luc Clement
Cc: mirek.novotny@systinet.com; Rob Kochman
Subject: AW: UDDI cr082 - Duplicative keyedReference in bags


Luc and all,


I believe that we altered the change initially requested by CR082 to the more general statement since keyedReferences are only one example where document order preservation is required.


The latest version of CR082 - on which I based my edits - is attached.



-----Ursprüngliche Nachricht-----
Von: Luc Clement [mailto:luc.clement@systinet.com]
Gesendet: Samstag, 20. November 2004 03:06
An: Von Riegen, Claus
Cc: mirek.novotny@systinet.com; 'Rob Kochman'
Betreff: RE: UDDI cr082 - Duplicative keyedReference in bags


Rob brought up a point that I can't make sense of. CR082 called for the addition of text in, ..16.3,.. 17.3 and ..18.3 by making the change specific to keyedReferences to the cat/id bags as follows: Behavior:
When a bindingTemplate is saved with a categoryBag content that is associated with a checked value set or category group system tModel, the references MUST be checked for validity prior to completion of the save, or the node must return E_unsupported, indicating it does not support the referenced checked value set or category group system. <Duplicative keyedReferences within a categoryBag MUST be unaltered to preserve the integrity of a digital signature.> See Section Error! Reference source not found. Special considerations for validated value sets and Appendix F Using Categorization for additional details.


The update I got from you did not make the changes in these locations - rather it changed 4.5.3 adding the text in bold red. This text is fundamentally different and impacts far more than was the CR was trying to deal with.

4.5.3 Preservation of Document Order
The UDDI data model requires UDDI nodes to preserve the order of all descendent elements in the UDDI core data structures.  When a UDDI node responds to an inquiry API call, the descendent elements of the core data structures in the response must have the order specified by their publishers or by the order of insertion.

<Preservation of document order in UDDI implies that all elements in a sequence MUST be preserved. It is a requirement not to de-duplicate elements of a sequence.>

Could you explain - did we decide to change this behaviour (as I sense we might have agree to)?



-----Original Message-----
From: Rob Kochman [mailto:robko@microsoft.com]
Sent: Friday, November 19, 2004 12:16 AM
To: mirek.novotny@systinet.com; Luc.Clement@systinet.com
Subject: UDDI cr082 - Duplicative keyedReference in bags

Hi, guys... I noticed that the wording added in the spec is more general than the original intent of change request 82.  The line added to 4.5.3 implies that all duplicates of *any* element in *any* sequence must be preserved, whereas the CR states that this applies to keyedReference in identifierBag and categoryBag.  I don't know what was discussed at the FTF, but was the intent to change the meaning?



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