Issue 157: Formalize processing model

[Reviving this thread for this week's telcon.]

As I recall, the issue [1] here is how precise we should be in defining
what it means to be a conformant WSDL processor.  Do we want to
enumerate the possible "paths" through the document, with the intention
that processing of such a path must be done in its entirety (e.g.
failing to understand a required extension anywhere within that path
must cause a conformant processor to fault)?

The conformance section of the spec [2] says:

  An extension element is said to be processed if the WSDL processor 
  decides (through whatever means) that its parent (an element 
  information item in the "http://www.w3.org/@@@@/@@/wsdl" namespace) 
  will be processed. Note that it is possible for WSDL processors to 
  process only a subset of a given WSDL document. For instance, a tool 
  may wish to focus on interfaces and operations only, and ignore 
  bindings. 

and

  - A conformant WSDL processor MUST fault if a portion of a WSDL
document
  is illegal according to this specification and the WSDL processor
  attempts to process that portion.

  - If a mandatory extension (i.e., a mandatory element, feature or 
  property) is processed, a conformant WSDL processor MUST either agree 
  to fully abide by all the rules and semantics signaled by that 
  extension, or immediately cease processing (fault). In particular, 
  if the WSDL processor does not recognize the extension, it MUST 
  fault. If the WSDL processor recognizes the extension, and determines
  that the extension in question is incompatible with any other aspect
  of the document (including other required extensions), it MUST fault.

Jacek put forward a proposal [3] that groups elements so that
conformance can be assessed at a finer granularity than the whole.  Here
I augment Jacek's list with specific text that could appear in the
bulleted list in our conformance section.  (Based on the pseudo-schema
in the current ed draft.)

>      1. inside definitions EII, imports and includes and types are
>         required (to process), interfaces, bindings and services are
>         optional

  - If a wsdl:definitions element is processed, a conformant WSDL
processor
  MUST also process the wsdl:import, wsdl:include, and wsdl:types
children
  of that element.

>      2. inside types, all is optional (we could mandate XML Schema
>         elements since every conforming WSDL processor is required to
>         know that)

We already say "A conformant WSDL processor MUST support at least XML
Schema as a type system language."  That seems sufficient.

>      3. inside interfaces, all is required

  - If a wsdl:interface element is processed, a conformant WSDL
processor
  MUST also process the wsdl:operation, wsdl:fault, wsdl:feature, and
  wsdl:property children of that element.

>      4. inside bindings, the same

  - If a wsdl:binding element is processed, a conformant WSDL processor
  MUST also process the wsdl:operation, wsdl:fault, wsdl:feature, and
  wsdl:property children of that element.

>      5. inside services, all endpoints are optional

So we don't have to say anything.

>      6. inside other elements everything is required

I don't think we want to require that wsdl:documentation be processed in
any case, so it's best to enumerate what "other elements" we're talking
about.

  - If a wsdl:operation element is processed, a conformant WSDL
processor
  MUST also process the wsdl:input, wsdl:output, wsdl:infault,
  wsdl:outfault, wsdl:feature, and wsdl:property children of that
element.
  
  - If a wsdl:property element is processed, a conformant WSDL processor
  MUST also process the wsdl:value and wsdl:constraint children of that
  element.

Hope this is a fruitful proposal for addressing the issue.  My 2 cents:
I'm having a hard time seeing what this will accomplish in the real
wold.

[1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x160
[2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html#proc
essor
[3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0121.html

Received on Tuesday, 22 June 2004 12:01:31 UTC