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: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
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
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: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?
Thanks...
-Rob