- From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Date: Wed, 23 Jun 2004 10:23:03 +0600
- 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 UTC