Title: Nachricht
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
