Title: Update to CR-034 (Creating self-referencing tModels)
Perhaps we can avoid your discomfort with my suggestion by making the
policy of whether to disallow references within the batch a policy that applies
to the registry as a whole, rather than on a node-by-node basis.
Oh, on re-reading your comments, I see that you've suggested the same
thing. :-)
Tony Rogers
-----Original Message-----
From: Von Riegen,
Claus [mailto:]
Sent: Thu 3/07/2003 20:59
To:
Cc:
Subject: [uddi-spec] Update to CR-034 (Creating self-referencing
tModels)
I took an action item at our May 27 TC meeting to
update CR-034 to meet the following requests:
"Claus took us through the description of this
CR. Tony would rather we disallow references to any tModels not already
in the registry. The problem here is that it imposes an extra check to
do the saves in the registry. A suggestion was made that we say nodes
"MAY" allow (1), but now (2) or (3). Things like service projections and
hosting redirectors would be complicated as well.
We agreed that the CR needs to be changed to get
around the problem by saying that a node MAY permit (1), but MUST disallow (2)
and (3). There is also some confusion in the CR indicating
the error condition as E_invalidKey. It should be E_invalidValue,
depending upon whether it's being used as the category, or as a value in the
category. Need to clarify. Also note that the entire request
may fail, saving the entities separately eliminates the problem. A
similar problem exists with hosting redirector.
Should we create a recommended policy on which
behavior the node supports? Claus will suggest one. Claus will change
the CR and resubmit."
After reviewing the CR and these requests again, I
now believe that the requests lead to additional problems/questions.
1) Tony's suggestion that a node MAY disallow
references to any tModels not already in the registry is not acceptable since
this may result to a situtation where one node in a registry decides to allow
such references and another decides to disallow them. If such data is
replicated from the first node to the second, this would result in an
unacceptable replication error.
As a result, two alternatives remain: either we
decide that the behavior with regard to such references (allow or disallow
them) MUST be specified on registry level or we decide that they are always
allowed, that is, we stay with the currently specified (V3)
behavior.
2) I don't recall why there was a discussion about
including E_invalidValue as a possible error condition. A tModelKey in a
keyedReference is always a tModelKey, and if it is invalid the E_invalidKey
error condition applies. A tModelKey can certainly be used as a keyValue in a
keyedReference (remember our discussion on value sets that are based on entity
keys) but whether the key is valid or not is a matter of value set validation.
This is specified in a separate section (5.2.3) and the corresponding error
condition is already listed in section 5.2.18.5 of the save_tModel API call
section.
As a result, I don't see a need to update the
specification in this regard.
3) Depending on the outcome of 1), we may even
don't need a corresponding policy.
I'd be interested in differing opinions so that I
can update the CR, if required.
Regards,
Claus
