- From: Yuhichi Nakamura <NAKAMURY@jp.ibm.com>
- Date: Fri, 30 Mar 2001 09:57:03 +0900
- To: xml-dist-app@w3.org
Mark, 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