Comments on Part 2, Chapter 6

More comments:

1. In 6. the paragraph:

"As allowed in [WSDL 2.0 Core Language], a Binding component MAY exist 
without indicating a specific Interface component that it applies to. In 
this case, there MUST NOT be any Binding Operation or Binding Fault 
components present in the Binding component."

Is not a new requirement. It reproduces a requirement from Part 1. It 
should contain the keywords MAY, MUST NOT since it is not a new 
requirement. It should be rephrased as a note. It is equivalent to the 
Part 1 assertion:

"If a Binding component specifies any operation-specific binding details 
(by including Binding Operation components) or any fault binding details 
(by including Binding Fault components) then it MUST specify an interface 
the Binding component applies to, so as to indicate which interface the 
operations come from.? " which is Binding-0054. Perhaps include a 
reference to Part 1 here.

2. In 6.3.1 HTTP Method Selection, there is no value specified when all 
the conditions fail. What is the default? I suggest POST.

3. In 6.5.3 HTTP Header Component the {type definition} component is 
defined as a QName reference to a Type Definition component. This is 
inconsistent with the way refrences are handled in the Core spec. This 
property should be changed to be a Type Definition component, i.e. the 
resolved value of the QName. Note that Table 6-3 correctly decsribes this 
property as a Type Definition, not a QName.

4. In 6.7 Serialization Format of Instance Data, Table 6-5, why is the 
application/xml the only mime type that can be returned on the output 
message? The other two types might also be useful in outputs. Multipart 
output seems reasonable.  URL encoded output is less likely.

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