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:claus.von.riegen@sap.com] Sent: Wed 24-Nov-04 7:37
To: Rogers, Tony; Luc Clement; uddi-spec@lists.oasis-open.org
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
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:luc.clement@systinet.com] Sent: Tue 23-Nov-04 7:43
To: uddi-spec@lists.oasis-open.org 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
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
|