Comments on Primer Sections 4 - 6.5

1. Section 4. The text:

A WSDL description must NOT refer to XML Schema components that are 
neither imported nor embedded into that WSDL description. In other words, 
the use of xs:import and/or xs:schema is a necessary condition for making 
XML Schema components available to a WSDL Description component. 

should be stated positively, e.g. 

A WSDL description must use either xs:import or xs:schema to define XML 
Schema components that are refered to by WSDL components.


2. Section 4.2 The text:

The xs:import mechanism is not transitive. Only components defined in the 
imported schema itself and components the schema includes via xs:include 
are available to the containing WSDL document. Specifically, components 
that the schema imports via xs:import are NOT available to WSDL. 

should be rewritten to avoid the use of the term "transitive". e.g.

A WSDL document must define XML Schema components (within the types 
element using either xs:import or xs:schema) that are refered to by WSDL 
components. The XML Schema components defined within xs:schema may be 
defined using xs:include. In constrast, within xs:schema an xs:import does 
not define any components, but only declares a namespace. 

3. Section 4.3, Table 4-1

The transitive column should be eliminated. The Meaning column should be 
rewriten to avoid the notion of merging. It should use the notion of 
declaring namespaces and defining components.

The last row should be labelled xs:include.

4. Section 5.1 The code example has bad alignment:

      <input messageLabel="xs:NCName"? 
                                         element="union of xs:QName, 
xs:Token"? >
      </input>*

      <output messageLabel="xs:NCName"? 
                                         element="union of xs:QName, 
xs:Token"? >
      </output>*

5 Section 5.2. The following text is wrong:

Finally, since faults, features and properties can also be defined as 
children of the interface element (as described in the following 
sections), the same name-collision rules apply to those constructs. 

The name collision rule only applies to faults. For features and 
properties, you can special those you inherit via the composition rules.

6 Section 5.3. This text is wrong:

The fault element has a required name attribute that must be unique within 
the WSDL document's target namespace, and permits it to be referenced from 
operation declarations.

The name attribute is only required to be unique within the Interface. It 
is like <operation>.

7. Section 5.4.1 Update this section to reflect the change to the {safety} 
property

8. Section 5.4.2 Update this text to describe #other

The element attribute is also optional. If it is not specified, then @@@@. 


Should be:

The element attribute is also optional. If it is not specified, then 
#other. 

9. Section 6.1. Shouldn't this lisitng include <infault> and <outfault>?

    <operation ref="xs:QName" >
      <input messageLabel="xs:NCName"? > </input>*
      <output messageLabel="xs:NCName"? > </output>*
    </operation>*



Arthur Ryman,
Rational Desktop Tools Development

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
intranet: http://labweb.torolab.ibm.com/DRY6/