- From: Arthur Ryman <ryman@ca.ibm.com>
- Date: Tue, 1 Feb 2005 17:56:11 -0500
- To: www-ws-desc@w3.org
- Message-ID: <OF0740F837.4D4F3ABE-ON85256F9B.007CBD13-85256F9B.007DFBE5@ca.ibm.com>
David, I think Option B is the simplest. XSD support is described in Part 1, so it should be clear that it's part of the core language. 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/ www-ws-desc-request@w3.org wrote on 01/31/2005 04:42:43 PM: > > This is in completion of our action item: > [[ > 2004-11-09: DBooth and Roberto to describe > option 2 (remove definition of processor > conformance, write up clear guidelines > to developers) (LC5f) > ]] > > The objective of this action was to eliminate the notion of "conformant > WSDL processor", express the requirements in terms of document > conformance, and move any further guidance about processor conformance > that seems necessary to non-normative notes. Here are our proposed > changes. > > 1. Abstract: Delete "It also defines criteria for a conformant processor > of this language." > > 2. Section 1 Introduction: Delete "It also defines criteria for a > conformant processor of this language." > > 3. Section 3 Types: Delete the Note: > [[ > Support for the W3C XML Schema Description Language [XML Schema: > Structures],[XML Schema: Datatypes] is required of all processors. > ]] > > 4. Section 3.1 Using W3C XML Schema Description Language: > Delete: "All processors MUST support XML Schema type definitions." > > 5. Section 4.1.1 location attribute information item with include > [owner]: > Change: > [[ > If the URI indicated by location is not dereferenceable or does not > resolve to a WSDL document then the processor MUST fail immediately. > That is, include elements MUST be processed immediately by WSDL > processors. > ]] > to: > [[ > The URI indicated by location MUST be dereferenceable to a WSDL > document. > ]] > > 6. Section 4.2.2 location attribute information item with import [owner]: > Change the following sentence into a non-normative Note: > [[ > This allows WSDL components to be constructed from information other > than serialized XML 1.0. It also allows the development of WSDL > processors that have a priori (i.e., built-in) knowledge of certain > namespaces. > ]] > > 7. Section 6.1.1 Mandatory extensions: > In the first Note, after the sentence: > [[ > Thus, the meaning of the element may not be fully understood without > understanding the attached extension. > ]] > add the sentence: > [[ > Thus, a processor encountering an unknown mandatory extension would not be > able to safely process the WSDL document. > ]] > > 8. Section 8.1 Document Conformance: > In the first paragraph, append to the end of the last sentence: > [[ > and, by delegation, the specifications defining any mandatory extensions > that are used, as explained in Section 6.1.1 Mandatory extensions. > ]] > > 9. Section 8.3 Processor Conformance: Delete this section. > > Those are the specific changes that we propose. However, we were unsure > of how to handle one issue: the issue of requiring XML Schema support. > For this issue we thought we'd present three alternatives and see what > the WG thinks is best. The basic issue is that if we remove the > definition of a "conformant WSDL processor", then there really is no way > to say how much or what kinds of WSDL documents a WSDL processor must > support. The best one can do is to define what constitutes a part of > the WSDL 2.0 language, and if something is a part of the WSDL 2.0 > language, then effectively it must be supported by every WSDL processor > that supports the whole WSDL 2.0 language. > > Here are three options: > > Option A: Treat xs:schema and xs:import as any other extensions in WSDL > 2.0, which means that the user would have to add wsdl:required='true' > each time they are used. This also means that WSDL processors would not > be required to support XML Schema. (However, if a WSDL document > contains an xs:schema with wsdl:required='true' then the processor of > *that* document would have to support XML Schema, of course.) > > Option B. Treat xs:schema and xs:import specially in WSDL 2.0, and say > that there is an implicit wsdl:required='true' on each of them. This > would not exactly have the effect of requiring all WSDL processors to > support XML Schema, because WSDL documents that don't use xs:schema or > xs:import still would not need XML Schema support. But it would mean > that any WSDL document that uses xs:schema or xs:import clearly would > require a processor that supports XML Schema. > > Option C: Define new elements in the WSDL 2.0 namespace, wsdl:xs-schema > and wsdl:xs-import, whose semantics would be defined directly in terms > of xs:schema and xs:import. This would have the effect of requiring > every WSDL processor that supports the whole WSDL 2.0 language to > support XML Schema, because these constructs would be a part of the WSDL > 2.0 language. The downside of this is that you could not directly > insert a conventional xs:schema in a WSDL 2.0 document, because the > top-level element of that subtree would need to be wsdl:xs-schema > instead of xs:schema. > > -- > > David Booth > W3C Fellow / Hewlett-Packard > >
Received on Tuesday, 1 February 2005 22:56:48 UTC