RE: [uddi-spec] further comments on 3.0.1

Title: [uddi-spec] FW: [ebxml-jc] Changes for the <overviewURL>s in uddi-spec-tc-tn-uddi-ebxml-updatedoverviewURLs

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



  
-----Original Message----- 
From: Rogers, Tony 
  
Sent: Thu 14/08/2003 12:56 
To: Luc Clement; 
   
Cc: 
Subject: [uddi-spec] 
  further comments on 3.0.1

  
Section 5.1.12.3: omits description from the diagram for serviceInfo. I 
  thought there was an approved CR requiring the addition of description to 
  serviceInfo throughout?

  
 

  
- - - - - -

  
 

  
Section 5.2.2.1.1 is confusing. I found the pseudo-code difficult to 
  decypher, and the presence of (first example) and (second example) in the 
  table had me looking at the pseudo-code for two instances of the (case 4) 
  label. I recommend, at least, removing the (first example) and (second 
  example) comments from the table - trust the reader to work out that there are 
  two examples.

  
 

  
I'd suggest re-writing the pseudo code as follows to make it easier to 
  read:

  
 

  
1.      if x is a keygeneratorkey, and y is that 
  key without the :keygenerator suffix, then:

  
1.a      if y is a domain key, then x is a 
  top-level keygenerator, and has no keygeneratorkey

  
1.b      if y is a derived key, and z is the key 
  on which it is based, then x's keygeneratorkey is z:keygenerator

  
2.      if x is a domainkey, then x's 
  keygeneratorkey is x:keygenerator

  
3.      if x is a derivedkey, and y is the key 
  on which it is based, then x's keygeneratorkey is y:keygenerator

  
 

  
this gets the nasty case out of the way first, and lets us glide over the 
  question of whether a keygeneratorkey is a derived key (the earlier discussion 
  suggests that it is not). If we use this pseudo-code, then the numeric 
  references in the table become: 2, 1.a, 1.b, 3, 3.

  
 

  
- - - - - -

  
 

  
Section 5.2.8 delete_business has footnote 21, which ends: ", or matching 
  serviceKey values between businessService elements and bindingTemplate 
  elements." - this suggests the possibility of bindingTemplate projections, 
  which are not mentioned anywhere else in the standard that I've seen - I 
  recommend removing this fragment from the footnote to avoid confusion.

  
 

  
Section 5.2.16.1  specifies the cardinality of the businessEntity 
  list as 0 to infinity in the diagram, which disagrees with the text in 
  5.2.16.2 which says "Required repeating element containing one or more". 
  Clearly either the diagram or the text is wrong. I think the diagram should be 
  corrected, for consistency with the other APIs.

  
 

  
Section 5.2.16.3 third paragraph uses "different than", which is 
  grammatically incorrect - should be "different from".

  
 

  
Section 5.2.17.5 bullet points for E_invalidKeyPassed, E_unsupported, and 
  E_unvalidatable mention "should" which should be "SHOULD" for consistency with 
  the other bullets.

  
 

  
Section 5.2.18.3, first paragraph. "any empty uddiKey" should probably be 
  "an empty uddiKey", given that the is only one in the tModel under 
  consideration (the phrase is qualified with "If the new tModel...").

  
 

  
 

  
 

  
There are a number of places where the construct "publisher that" is 
  used. These really should be "publisher who" - I can call out all the 
  locations if required, but a global search/replace can do this equally 
  well.