RE: [uddi-spec] FW: UDDI cr082 - Duplicative keyedReference in bags

Title: Nachricht

The question of multiple top-level keyed entities in a save_X call is 
already covered - that is, the standard does describe what to do with multiple 
occurrences of a business entity in save_business, multiple occurrences of a 
service in save_service, and so on - the answer is that the last instance is the 
definitive one. 

 

This does not apply to our current problem, though, because the list of 
businesses in a save_business call is not covered by a digital signature. 

 

What is not covered is multiple occurrences of a given service within a 
single business, or multiple instances of a binding template within a service 
(possibly within a business). In other words, the standard doesn't cover 
multiple occurrences of a particular keyed entity within another keyed 
entity.

 

The only issue is with save_business and save_service. The save_binding and 
save_tModel calls do not have the option of saving a list of keyed entities 
within another keyed entity.

 

I suggest that we need some words under save_business and save_service to 
clarify this, plus some words similar to those Claus specified below. 
We should also point out somewhere that resolving this problem 
(de-duping a list of keyed entities) will break signatures.

 

This is definitely a topic for discussion at next week's meeting.

 

Tony

  
-----Original Message----- 
From: Von Riegen, 
  Claus [mailto:] 
Sent: Wed 24-Nov-04 7:37 
  
To: Rogers, Tony; Luc Clement;  
  
Cc: 
Subject: AW: [uddi-spec] FW: UDDI cr082 - 
  Duplicative keyedReference in bags

  
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