Part 2 Adjuncts Comments (1 -5)

I reviewed Part 2 carefully and have the following questions up to the end 
of chapter 5:

1. In 4.2 IRI Style, the content model of the initial is constrained to 
have a sequence of child elements. What are the occurrence contraints? Are 
there any?

2. In 4.2 IRI Style, the last bullet says: "If the children elements of 
the sequence are defined using an XML Schema type ...". What else could 
they be defined as? Don't all elements have a type?

3. In 5.3 SOAP Binding Rules, the rule about mustUnderstand seems weak. If 
the SOAP Header block is marked as mustUnderstand=true in WSDL, then 
shouldn't the header in the SOAP message also have mustUnderstand=true?

4. In 5.6.2, isn't {soap fault codes} really a set and not a list? The 
order of subcodes is irrelevant and it doesn't make sense to repeat a 
subcode. Sounds like a set. Also, is there a difference between having an 
empty set of subcodes and #any. I assume #any means any subcode may be 
used. Does an empty set mean the subcodes are never used?

5. Global comment on organization: Part 1 is organized by component, and 
then by properties within a component. In Part 2 this structure in not 
used. Components and properties are described together. I think it would 
be clearer is we followed the Part 1 organization, i.e. have a section for 
each Core and Extension component involved, then list and describe the 
properties that apply to each compoinent. e.g. 5.7.2 lists a set of 
properties, but some apply to Binding and some apply to Binding Operation 
- sort of confusing I think.

6. In 5.7.2 is there any constraint between WSDL meps and SOAP meps, i.e. 
if an operation uses a given WSDL mep, then does that restrict the allowed 
SOAP mep used in the biniding?

7. In 5.7.2 there are defaulting rules for {soap mep} but is a value for 
the actual SOAP mep required, i.e. must the defaulting rules produce a 
definite value?

8. In 5.8.2 there should be a constraint on {soap modules} that each soap 
module component is uniquely identified by its {ref} property, i.e {ref} 
is a key. No two different soap modules in the {soap modules} property may 
have the same {ref}.

9. Similarly, in 5.9.2 there should be a contraints on {soap headers} that 
each soap header component is uniquely identified by is {element 
declaration} property (I assume).

10. In 5.9.6, the design of the fragment identifier for wsoap.header is 
inconsistent since it represents the element QName as namespace#name. All 
other components use the QName and define the namespace using an xmlns 
pointer part. This should be changed to use QName too, c.f. the element 
declaration component itself.




Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca