rationale for rejecting LC75a

Jonathan asked me to write this up a few moons back. Sorry about
the slight delay ;-).

===========================

> Section 2.3: Fault declarations should be moved down into
> interface/operation, and not be defined as first-class components of
> interface.  Fault references ought to work as message references do:
> 
> * The following argument from Section 2.3.1 applies equally well to
> messages.  Why aren't they treated consistently?  "The Interface Fault
> component provides a clear mechanism to name and describe the set of
> faults an interface may generate.  This allows operations to easily
> identify the individual faults they may generate by name.  This
> mechanism allows the ready identification of the same fault occurring
> across multiple operations and referenced in multiple bindings as well
> as reducing duplication of description for an individual fault."

If we do this with messages then we're back to the dreaded
<message> construct, which the WG decided to remove after much
pain and labor. We do not wish re-open that particular can-o-
rotten-worms.
 
> * Interface Fault Components are not globally reusable.  The solution is
> half-baked.

They are globally reusable - just put any faults you want to reuse
globally into its own interface and extend from that wherever
you want to reuse those faults.

While its not necessarily the optimal solution, it is a viable
workaround.
 
> * Interface Fault Components do not provide any practical re-use.  The
> 99% case just renames @element.

We do believe they support a fairly common case of multiple operations
within the same interface throwing the same fault. While whether that's
the 80-20 case is certainly a subjective decision, it is indeed a 
practical use-case.

> * Interface Fault Components are awkward because they cannot be bound
> within the context of an operation, preventing, for example, the
> assignment of a different reason string to the 'same' fault within
> different operations.  Making these 'error messages' clear for debugging
> scenarios will require creating Interface Fault Components that are
> otherwise identical.

We debated this point and concluded that reason strings should not be
changeable across usages of the same fault in different operations. If
you want you may of course send different details but the reason
should be fixed. That's precisely the common point across the faults
in the interface.
 
> * It would be much cleaner if the Interface Operation and Binding
> Operation components had parallel properties.  As it is, only one has
> {fault references}.

We considered this but it leads to much complexity. If we hoist Interface
Fault components to the same level as Interface components, then you
need separate Binding components for Faults and Interfaces as well as
a way to combine them to form a complete binding. The WG did not feel that
that was the 80-20 design point we wished to go for.

===========================

Sanjiva.

Received on Monday, 28 February 2005 17:17:21 UTC