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