RE: Issue 157: Formalize processing model

At 12:11 PM 6/23/2004 -0700, Jonathan Marsh wrote:
>If I understand it correctly, processing of wsdl:documentation elements
>would be required under your proposal, whatever that means.

It probably makes more sense to add wsdl:documentation to the list of 
elements that could be ignore if not needed.

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

I may not understand what you mean here.  Since wsdl:definitions is the 
wrapper around everything else, it seems to me that it must be processed if 
*any* part of the document is going to be processed.  And I would think the 
imports and includes should be processed because they *might* contain 
required extensions.

Regarding the wsdl:types element, that seems like another possible 
candidate for the list of elements that could be ignore if not needed.

Incidentally, I would be fine with either approach.  I just offered this 
approach because it was seeming to me that it would be simpler.  Maybe we 
should just take a straw poll to see which approach others prefer.


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

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

Received on Wednesday, 23 June 2004 17:39:34 UTC