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

Re: Processing model

From: marc hadley <marc.hadley@Sun.COM>
Date: Tue, 22 May 2001 15:02:24 +0100
Message-ID: <3B0A7170.3EC4F677@Sun.COM>
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]


[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

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