Re: A scenario investigating questions of conformance and scoping

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

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

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

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Monday, 23 February 2004 16:58:33 UTC