RE: Issue 157: Formalize processing model

If I understand it correctly, processing of wsdl:documentation elements
would be required under your proposal, whatever that means.  And
wsdl:definitions is another difference.  In your formulation if I
extracted a wsdl:binding, I would still have to process wsdl:definitions
which means you have to process imports and includes, types, and check
for required extensions which may not have anything to do with the
binding.  Is that the behavior we want?

> -----Original Message-----
> From: David Booth [mailto:dbooth@w3.org]
> Sent: Tuesday, June 22, 2004 2:20 PM
> To: Jonathan Marsh; Web Services Description
> Cc: Jacek Kopecky
> 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#pro
c
> >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 15:12:26 UTC