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

Re: Action item on changing processor conformance to document conformance

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 GMT

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