W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2001

Re: AMG: New AM document snapshot 27th March 2001

From: Yuhichi Nakamura <NAKAMURY@jp.ibm.com>
Date: Fri, 30 Mar 2001 09:57:03 +0900
To: xml-dist-app@w3.org
Message-ID: <OF2FE3D489.3A8613C9-ON49256A1F.0003C508@LocalDomain>

Thanks for your prompt reply.

>If this is an intentional fault generated by a handler, there are
>a couple of reasonable possiblities:
>a) fatally fault and propagate back to the sender if possible
>b) insert a block that contains information about the problem
>and targeted that to a processor that can handle the fault.
>This could be the final destination, for example.  It could
>also be a fault-managing intermediary that might have another
>way to compensate for the problem or to report the problem.
Well, this is how to handle the fault by "another" application.
I am talking how to handle the fault and related informaiton "within"
the application.  For example, when a verfication of digital signature
fails, you may want to log "detailed" reason of the failure and its
original message.  Such information is available in "the" application.
So the term "fault handler" is not adequate.  It could be "exception
handler" for clarification.
I think this kind of exception handler is required anyway in realistic
applications.  However, I am not sure whether such handler should
be discussed in this abstract model.

>Presumably, the sender has to provide some information confirming
>whose digital signature block should be inserted.  The sender does
>this by providing this information in a block that requests that a
>digital signature block be added.  This requesting block basically
>gets replaced by the inserted signature block.
>There is no mechanism for just firing a handler since it is dispatched
>using information in a block.  You could have an intermediary that
>dispatched a given handler on any block targeted at its processor
>(e.g., by using the .../next actor URI).  It could insert anything it
>wanted and reinsert the matching block (retargeting it to .../next,
>for example).
This is reasonable when we take handler b-c-f chain in Figure 2.1.
I took handler d-g chain in the figure.  I thought that just firing
a handler with respect to this.   I suspect that this document
describes block cosuming, but not block producing clearly.
Am I right?

Best regards,

Yuhichi Nakamura
IBM Tokyo Research Laboratory
Tel: +81-462-73-4668
Received on Thursday, 29 March 2001 19:57:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:12 UTC