W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2004

Re: Issue 157: Formalize processing model

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: Wed, 23 Jun 2004 10:23:03 +0600
Message-ID: <023a01c458d9$e2250140$9f484109@LANKABOOK>
To: "David Booth" <dbooth@w3.org>, "Jonathan Marsh" <jmarsh@microsoft.com>, "Web Services Description" <www-ws-desc@w3.org>
Cc: "Jacek Kopecky" <jacek.kopecky@deri.at>

+1 to putting some minimalist wording in .. at best.

Sanjiva.

----- Original Message ----- 
From: "David Booth" <dbooth@w3.org>
To: "Jonathan Marsh" <jmarsh@microsoft.com>; "Web Services Description"
<www-ws-desc@w3.org>
Cc: "Jacek Kopecky" <jacek.kopecky@deri.at>
Sent: Wednesday, June 23, 2004 3:19 AM
Subject: 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 Wednesday, 23 June 2004 00:24:01 GMT

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