[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

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.