Re: proposal for faults

Ah! I think I *finally* understand the fault rules. I'm afraid 
the patterns document is *woefully* under-worded to explain 
what these things mean. 

Its prolly not a good idea to try to grok this @ 2:30am, but I'd
like to get this sorted out. Here goes:

> In the first pattern, the only place a fault can occur is replacing
> message M2.  Note that this could be minimized, in the same way that
> input/@messageReference and output/@messageReference can be minimized
> (omitted, that is).  If there's only one thing it can be, then it
> becomes optional.
> 
> In the second pattern, a fault may be triggered by either message.  The
> fault/@messageReference is therefore required (although
> input/@messageReference and output/@messageReference could be omitted). 
> In the second example, fault F1 may be sent in either direction; F2 can
> only be triggered by message M1, and F3 can only be triggered by M2.

Thanks for this example! It finally makes the two fault rules
clear to me. I think we need to include something like this
in the patterns spec for each pattern. (Non-normative examples
are fine, but something is needed.)

> I *really* don't want to fall back into the place where we have to
> define every possible location in which a fault occurs, which the
> proposal I'm responding to seems to require.

Yes, it did because that's how I had understood faults to be working
in the patterns document. My mistake, but now corrected (I think ..)!

> > Thus, whether a fault is inbound or outbound is fully determined 
> > based on the messageReference the fault element indicates. 
> 
> Still true, largely.  Actually, in the examples I provide above,
> direction is determined by @messageReference + the fault ruleset used by
> the pattern.  The relationship is probably slightly more obvious for
> fault-replaces-message.  An interesting variation might be: use
> attributes @replaces="messageReference" or
> @triggeredBy="messageReference".

An interesting variation indeed, but I don't think putting the
fault gen rules right in the user's face like that will be the
right thing to do. 

BTW, is it the case that only one fault rule is used by a given
pattern? That is, do we not allow one part of a pattern to use
FRM and another part MTF? I sure hope not ...

So, it seems to me that the syntax proposal I made to Jeffrey
is still acceptable, but the difference is that the value of
operation/fault/@messageReference would resolve to any message
ref in the pattern as there is nothing called a special fault 
message reference in the pattern. Then, in combination with 
the fault rule of the pattern, that unambigiously states what
the fault is and who's sending it to who. 

Amy/Jeffrey: Do you guys agree? If so I will send a summarized
proposal to try to get closure on this as I doubt everyone 
followed this thread carefully. 

Sanjiva.

Received on Thursday, 2 October 2003 16:44:49 UTC