RE: Issue 160 [was 157]: Formalize processing model

Oops, just realized I got the Issue number wrong on this one.  Should be
160.

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
On
> Behalf Of Jonathan Marsh
> Sent: Tuesday, June 22, 2004 9:01 AM
> To: Web Services Description
> Subject: 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 Wednesday, 23 June 2004 15:03:49 UTC