Re: Processor conformance: fault on non-conformant input

On Tue, 23 Mar 2004 12:09:38 -0800
Umit Yalcinalp <umit.yalcinalp@oracle.com> wrote:
> Sanjiva Weerawarana wrote:
> 
> >While I did indeed argue for any busted part stopping the processor,
> >I do understand the (and accept) the argument that one must be able
> >to skip parts that one doesn't care about. In particular, suppose
> >there's a .Net binding in a WSDL and one of the QName references in
> >there is busted. Let's say (just for the sake of argument) that
> >Oracle doesn't support the .Net binding and so doesn't understand
> >the elements of the .Net binding namespace and their (bad) cross
> >referencing habits. 
>
> What I am particularly concerned about bindings we define normatively
> in our specification, not an extension, such as HTTP binding and
> processors choosing to skip it and calling themselves conformant, even
> if there is a bug in the document they process.
> 
> The question is that how one tests a processor to be conformant or
> not? If a conformant processor can choose "portions of a document",
> this means the requirement is NOT testable unless we exactly define
> the "required profile" that a conformant processor MUST process. (I
> think I made this point during the f2f as well).

I do not believe that this is true.

If we wish to test processor conformance, it is perfectly
straightforward to define a minimal WSDL which expresses a particular
binding.  It can then be supplied to the processor.  Does it understand?
 Good.  Supply the same thing, broken in one way or another.  Does it
fail?  Good.  If there is only one path through the WSDL, it's easy
enough.

The idea that a processor *must* fail if there is an error somewhere in
the WSDL that it doesn't care about is, I believe, an utter mistake.  We
could say that processors have to do this, but they *won't*.  It simply
*will not* get implemented this way, universally.  If there is a good
HTTP binding for interface A, and a bad one for interface B, and the
processor is using interface A, then it is absolutely guaranteed that
someone is going to write a processor that doesn't even look at
interface B.

And they will have done so *rightly*, because that is what their
customers are after.  If it correctly processes interface A, then all is
serene.  It should fail if it needs to process something in interface B.

If someone wants to write up what the scope of a processor is for
conformance testing, I'm fine with that.  I think anyone interested in
doing so might want to pick up Glen's discussion of the scope of
features and properties, since it's *the same thing* (well, more or
less, anyway).

If my processor is asked to examine a WSDL for operation X, then I
should look at the interface containing X, the associated element
definitions, the binding for that interface, and the service that
contains the endpoint I know that I am using.  If there is also an
operation Y, in the same interface, that has a misspelled MEP URI, then
as far as I'm concerned it's irrelevant.  If the "input" message in
operation Y is lacking an "element" attribute, I don't care--I'm not
interested in operation Y.  If it contains fault definitions while
pointing at a MEP with the no-fault ruleset, I'm not going to fail to
process operation X, because I don't care about silly superfluous faults
in operation Y.  But if *any* of those things, or other WSDL-validity
errors, are in my processing path for operation X, then my processor
will fail (and so will someone else's, presumably).  All serene.

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

Received on Tuesday, 23 March 2004 15:42:54 UTC