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 5.2.17.3 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 5.2.17.3 save_service" 
may help. Are we able to clarify this even after the public 
review?

 

Claus

 

  

  
  -----Ursprüngliche 
  Nachricht-----
Von: Rogers, Tony [mailto:] 
  
Gesendet: Montag, 22. November 2004 23:06
An: Luc 
  Clement; 
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?

  
 

  
Tony

  
    
-----Original Message----- 
From: Luc Clement 
    [mailto:] 
Sent: Tue 23-Nov-04 7:43 
    
To:  
Cc: 
    
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

    
 

    

    

    
Luc 
    Clément
Senior Program Manager, 
    Systinet
Tel: +1.617.768.4268 / Cell: +1.978.793.2162 / www.systinet.com

    

    
    From: Rob Kochman 
    [mailto:] 
Sent: Monday, November 22, 2004 
    15:30
To: Luc Clement; Von Riegen, Claus
Cc: 
    ; 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?

    
 

    
Thanks...

    
 

    
-Rob

    
 

    

    

    
    

    
From: Luc 
    Clement [mailto:] 
Sent: Saturday, November 20, 2004 2:11 
    PM
To: Rob Kochman; 'Von 
    Riegen, Claus'
Cc: 
    ; 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

    

    
 

    

    
Luc

    
 

    

    
    

    
From: Rob 
    Kochman [mailto:] 
Sent: Saturday, November 20, 2004 
    16:52
To: Von Riegen, 
    Claus; Luc Clement
Cc: 
    
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:] 
Sent: Saturday, November 20, 2004 7:01 
    AM
To: Luc 
    Clement
Cc: 
    ; 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.

    

    
 

    

    
Claus

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

      

Claus, 

      
Rob brought up a point that I 
      can't make sense of. CR082 called for the addition of text in 5.2.15.3, 
      ..16.3,.. 17.3 and ..18.3 by making the change specific to keyedReferences 
      to the cat/id bags as follows:

      
5.2.15.3 
      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)? 

      
Luc 

      
 

      
-----Original 
      Message----- 
From: Rob Kochman 
      [mailto:] 
      
Sent: Friday, November 19, 
      2004 12:16 AM 
To: 
      ;  
      
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?

      
Thanks... 

      
-Rob