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

Re: A scenario investigating questions of conformance and scoping

From: Amelia A Lewis <alewis@tibco.com>
Date: Mon, 23 Feb 2004 16:58:39 -0500
To: Jacek Kopecky <jacek.kopecky@systinet.com>
Cc: www-ws-desc@w3.org
Message-id: <20040223165839.2a751bae.alewis@tibco.com>

Dear Jacek,

On Wed, 18 Feb 2004 16:52:58 +0100
Jacek Kopecky <jacek.kopecky@systinet.com> wrote:
> I think this all boils down to what is and isn't optional where.

Well, if you want it to, it can.

The actual case that I had in mind was whether it was possible for some
process that makes use of WSDL in the context of a particular message
exchange to do so, even if the WSDL contained unknown required elements
outside the scope of that message exchange, and even if the WSDL was
WSDL-invalid outside the scope of that particular exchange.

Your response seems to be: no, and no.  If there are required things,
then even if they aren't in the scope of the particular message being
handled, stop processing.  If there are invalid things, ditto.  Fair

> We've established that extensions not marked as required are optional
> and may be ignored by a successful parsing process.

Sure.  But suppose I'm doing operation X, and there's a required
extension on operation Y that I don't understand?  Succeed?  Fail?

> My view is that considering only the WSDL core elements, the following
> optionality rules should apply:
>      1. inside definitions EII, imports and includes and types are
>         required (to process), interfaces, bindings and services are
>         optional

Okay.  An error of WSDL validity in these areas *should* or *must* cause
an end to processing.

>      2. inside types, all is optional (we could mandate XML Schema
>         elements since every conforming WSDL processor is required to
>         know that)

Hmm.  Actually, I would either track a path (must understand the message
pointed to by the input/output/fault being examined), or that the
processor *must* understand the types.  It would perhaps be interesting
to provide a choice between languages, but I don't think anyone's
actually going to use that, if we were to do it.  So I'd say, instead,
make understanding of all the schema definition required.

>      3. inside interfaces, all is required
>      4. inside bindings, the same
>      5. inside services, all endpoints are optional
>      6. inside other elements everything is required

Umm, here it all breaks down.  I'm a nice little client, I get a WSDL,
it has a binding I don't know.  But it has one I *can* use, and an
endpoint to correspond.  There's some outrageous bizarreness that I
completely don't comprehend in one of the operations referenced by the
binding that I want to use, but I don't want to use that operation. 
There's also a whole interface with security turned on, and I don't know
anything about security.

I can *understand* everything I need to understand in order to perform
the operation.  However, other parts of the WSDL are utter gibberish, to
me.  Should I be able to interact with the service?  Or should a
"conforming WSDL processor" refuse to read this thing, because there's
stuff in it (in irrelevant-to-the-task locations) that it doesn't

> Basically, when you "process a WSDL", you might collect the service
> names and ask the user which ones to use, ignoring the rest. When you
> "process a WSDL service", you could do the same with endpoints. But
> you couldn't ignore an operation in an interface that you choose to
> process(say because it is referenced by an endpoint you want to
> access).
> Do you agree with the above list? Should we add that list in the spec?

I don't think I agree entirely.  I do believe that we should require
complete understanding of the imports, includes, and types.  Beyond
that, I'm not at all sure that we're in agreement.

Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
Received on Monday, 23 February 2004 16:58:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:38 UTC