- From: Mark Jones <jones@research.att.com>
- Date: Wed, 28 Mar 2001 14:47:09 -0500 (EST)
- To: NAKAMURY@jp.ibm.com, skw@hplb.hpl.hp.com
- Cc: xml-dist-app@w3.org
Hi Yuhichi, Although you directed this at Stuart, I'll try to answer (too). To: "Williams, Stuart" <skw@hplb.hpl.hp.com> Cc: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org> From: "Yuhichi Nakamura" <NAKAMURY@jp.ibm.com> Date: Thu, 29 Mar 2001 00:30:48 +0900 Subject: Re: AMG: New AM document snapshot 27th March 2001 Hello Stuart, I have two questions on handlers. 1. Do you have fault handlers? XML Protocol Hanlders seem to consume blocks, so they are normal handlers. When a normal handler fails, we may want to invoke a fault handler which is associated with the normal handler. Was there some discussion on such fault handling? Or do you have another mechanism for fault handling? 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. 2. 4.1 seems to address how to process blocks that are included in a given message. Another possiblity is just to add new blocks to the given message, i.e. inserting digital signature block. We may want to provide such block-insertion handler, but I am not sure how such handler is invoked with this framework. 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). Mark Jones Best regards, Yuhichi Nakamura IBM Tokyo Research Laboratory Tel: +81-462-73-4668 From: "Williams, Stuart" <skw@hplb.hpl.hp.com>@w3.org on 2001/03/28 01:16 Please respond to "Williams, Stuart" <skw@hplb.hpl.hp.com> Sent by: xml-dist-app-request@w3.org To: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org> cc: Subject: AMG: New AM document snapshot 27th March 2001 Folks, Today's snapshot of the AM document is now on line at [1]. Significant changes from yesterdays version are listed below. Regards Stuart -- [1] http://www.w3.org/2000/xp/Group/1/03/27/XMLProtocolAbstractModel.html Changes from Draft of 26th March 2001 1. Replaced section 3 with alternate version posted in http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0229.html 2. Replaced section 5.1 with new text from Marc Hadley addressing Hugo's comments in: http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0221.html 3. Pruned ToDo's list above. 4. Pruned Issue's list.
Received on Wednesday, 28 March 2001 14:47:25 UTC