Action item on changing processor conformance to document conformance

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

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
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
The URI indicated by location MUST be dereferenceable to a WSDL

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

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 Monday, 31 January 2005 21:42:43 UTC