Re: Issue 157: Formalize processing model

Jonathan, 

I think your email is an excellent proposal. It doesn't seem to me that
the proposed text is too long and it seems clear enough, maybe with a
short paragraph explaining the rationale, as in the first paragraph of
the email below.

Also, the intention is much clearer to me from this than it would be
from the text David has proposed in a reply, therefore I favor
Jonathan's approach. Maybe instead of enumerating all the elements, we
could just say "all the WSDL elements (i.e. the elements in WSDL
namespace)". It would be an error for wsdl:binding to appear in
wsdl:interface and if you said nothing about that (as proposed), a
conforming processor could choose to skip that path. 8-)

Finally, I was writing the original email in order to clarify that this
is what we all think, e.g. that no operation can be omitted when
processing an interface but an endpoint can be omitted when processing a
service and stuff like that. I believe this clarification is the value
of this text.

Best regards,

                   Jacek Kopecky

                   Ph.D. student researcher
                   Digital Enterprise Research Institute
                   http://www.deri.org/




On Tue, 2004-06-22 at 18:01, 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
> 
>

Received on Wednesday, 23 June 2004 05:56:05 UTC