- From: Liu, Kevin <kevin.liu@sap.com>
- Date: Wed, 15 Jun 2005 19:49:12 +0200
- To: "Arthur Ryman" <ryman@ca.ibm.com>, <www-ws-desc@w3.org>
- Message-ID: <3470F33FF8ED12498D07F3A9651AA18E207A4C@uspale20.pal.sap.corp>
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 UTC