[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] further comments on 3.0.1
I slipped and pressed Send before I was finished :-) Continuing...
Section 5.2.18.5: bullets for E_unsupported and E_unvalidatable have
"should" instead of "SHOULD"
Section 5.2.19.4: I may have overlooked something, but I cannot see any way
that the returned publisherAssertions structure can contain anything different
from the supplied list of publisherAssertion objects (assuming that
set_publisherAssertions succeeds). Should we make a comment to that
effect?
Section 5.4.5.1: the diagram of the keyBag has the cardinality indicated on
the sequence symbol, rather than on the key symbol, which makes it inconsistent
with all the other diagrams. The cardinality should be moved to the key.
Section 5.5.12 first line: "Node" should be "node".
Section 5.6.2.5 second paragraph, first line: "UDDI MUST reject" should
probably be: "the UDDI node MUST reject".
Section 5.6.3.2: generally arguments have been discussed in alphabetical
order - is that important?
Section 5.6.3.3 first line: "value values" should be "valid values".
Section 5.6.3.5: everywhere else the error codes are listed without values
(meaning that they could be changed without impact). Should we remove the
values, such as "(10210)", from here?
Section 7.2.4 last paragraph, first sentence. I don't understand the
sentence: "A comsuming node MAY reset the originating USN another value that had
previously been requested for a given node." - I am guessing that a word is
missing. Perhaps "to" should be inserted after "USN"?
Section 7.3.9 third paragraph (last one before the diagram) contains
"...may be replicated with a given registry...". I think this should probably be
"...may be replicated within a given registry...".
Section 7.4.2.3: should it include the xml rendition of the success
dispositionReport? This is redundant, and just one more thing we have to change,
for example when the API version changes. I suggest deleting it.
Section 7.4.3.3: there is no specification of the return message. Is it
just the operatorNodeID? Or is it contained in something?
Section 7.4.4.3: should we have a diagram of the return message with the
highWaterMark vector?
Section 7.5.1, fourth last paragraph. "Thus, change datum can always be
propagated..." should be "Thus, change data can always be propagated...", or
possibly "Thus, changed data can always be propagated...".
Tony Rogers
tony.rogers@ca.com
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]