W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2005

RE: Comments on Primer Sections 4 - 6.5

From: Liu, Kevin <kevin.liu@sap.com>
Date: Wed, 15 Jun 2005 19:49:12 +0200
Message-ID: <3470F33FF8ED12498D07F3A9651AA18E207A4C@uspale20.pal.sap.corp>
To: "Arthur Ryman" <ryman@ca.ibm.com>, <www-ws-desc@w3.org>
Hi Arthur,
 
My comments below.  For those items we agree, please make the edits. 

Best Regards,
Kevin
  

 



  _____  

From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Arthur Ryman
Sent: Monday, Jun 13, 2005 12:35 PM
To: www-ws-desc@w3.org
Subject: 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. 


[Kevin] I am OK either way. 
 
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. 

[Kevin] I personally think the current text is easier to understand. why
we have to avoid the term "tranisitive"? I think the last two sentences
in the paragraph qualifies what we mean by "transitive" pretty well. 
 
 
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. 

[Kevin] if you can come up with better text, I am OK with the change
 
The last row should be labelled xs:include. 
[Kevin] good catch. it should  be changed
 
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>*

[Kevin] oops. should be fixed
 
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.


[Kevin] please remove f&P from the list of constructs
 
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>. 

[Kevin] hmm, I remember having an ed note in this section asking for
clarification on the scope of  fault uniqueness since the text in part 1
makes it sounds it has to be unique within the ns. So part 1 is
clarified? if so, I agree we should fix it here too.
  
7. Section 5.4.1 Update this section to reflect the change to the
{safety} property 

[Kevin] yeap
 
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. 

[Kevin] yeap
 
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>*

[Kevin] yes. 

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/
Received on Wednesday, 15 June 2005 17:49:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:36 GMT