Re: Issue 157: Formalize processing model

I've pondered this in the background over the past few months, and I have 
not been able to come up with anything that is sufficiently precise without 
being oppressively complicated.

I'm now thinking that it may be much simpler (and good enough) to approach 
it the other way: instead of saying what parts of the document MUST be 
processed, say what parts are NOT required to be processed.  In other 
words, how about if we instead say something like:

[[
Definition: An element is "not needed" if the WSDL processor does not need 
any of the information contained in that element.

A conformant WSDL processor MUST process every part of a WSDL document, 
EXCEPT for any element that is not needed AND is one of the following elements:

wsdl:service
wsdl:endpoint
wsdl:binding
(Not sure exactly which elements people would want to list here.)
]]

This approach is based on: (1) that it would be bad to permit conformance 
to be sloppy, because it would lead to interop problems (e.g., a WSD being 
acceptable by one (lax) WSDL processor, but rejected by another (stricter) 
WSDL processor); and (2) that it's mainly just the binding-specific part of 
the WSD that people want to be able to ignore if it isn't for a binding 
that they are using.

What do others think of this approach?


At 09:01 AM 6/22/2004 -0700, Jonathan Marsh wrote:

>[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

-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Tuesday, 22 June 2004 17:19:47 UTC