- From: marc hadley <marc.hadley@Sun.COM>
- Date: Tue, 22 May 2001 15:02:24 +0100
- To: xml-dist-app@w3.org
Hugo Haas wrote: > > * Doug Davis <dug@us.ibm.com> [2001-05-18 22:11-0400] > > - Taking a very literalist approach, the above list > > could be taken to imply that a SOAP/XMLP processor > > needs to scan the entire message in order to identify > > all of the blocks intended for it before can process > > any of them. Is this truly the intent? > > I don't think that the specification should force implementation to > identify all the blocks before processing them, although the text > indeed seems to go in that direction. I would tend to think that this > is a wording problem. > I think there are two issues here: (i) Error Handling Prescanning the entire message is an easy way to identify some errors (truncated message, malformed message) that might require the work of a handler to be rolled back when the error is found. Unfortunately such prescanning can't guard against the kinds of everyday runtime problems that can occur (e.g. out of disk space, dependent service not available, ...) with any piece of software. A robust server needs to provide mechanisms (transactions, output buffering etc) that allow the work of an earlier handler to be undone when a later handler faults for whatever cause so error handling isn't a good reason to mandate prescanning the entire message (though it might be a good optimisation). (ii) Block Ordering Processing blocks on a first come, first served basis imposes an implicit ordering on the blocks. This may not be desirable as outlined in Henriks message [1] Marc. [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0284.html -- Marc Hadley <marc.hadley@sun.com>
Received on Tuesday, 22 May 2001 10:02:25 UTC