Re: Issue 25 Proposal

In response to [1], I see the core issue as whether SOAP 
does or does not support a streamed processing model. The three section 
fragments below imply that it cannot if one takes a strict interpretation
of the SOAP1.1 specification (regardless of what Jacek points
out in [2] regarding current implementations doing an mU check on
the body entries):

2. The SOAP Message Exchange Model

	A SOAP application receiving a SOAP message MUST process that 
	message by performing the following actions in the order
        listed below:

              1.Identify all parts of the SOAP message intended for that 
		application (see section 4.2.2) 
              2.Verify that all mandatory parts identified in step 1 are 
		supported by the application for this message (see section
                4.2.3) and process them accordingly. If this is not the 
		case then discard the message (see section 4.4). The processor
                MAY ignore optional parts identified in step 1 without 
		affecting the outcome of the processing.
	...

4.2.3 SOAP mustUnderstand Attribute

        The SOAP mustUnderstand global attribute can be used to 
	indicate whether a header entry is mandatory or optional for the
        recipient to process. The recipient of a header entry is defined 
	by the SOAP actor attribute (see section 4.2.2). The value of
        the mustUnderstand attribute is either "1" or "0". The absence 
	of the SOAP mustUnderstand attribute is semantically
        equivalent to its presence with the value "0".

        If a header element is tagged with a SOAP mustUnderstand attribute 
	with a value of "1", the recipient of that header entry
        either MUST obey the semantics (as conveyed by the fully qualified 
	name of the element) and process correctly to those
        semantics, or MUST fail processing the message (see section 4.4).


4.3.1 Relationship between SOAP Header and Body

        While the Header and Body are defined as independent elements, they are 
	in fact related. The relationship between a body
        entry and a header entry is as follows: A body entry is semantically 
	equivalent to a header entry intended for the default
        actor and with a SOAP mustUnderstand attribute with a value of "1". 
	The default actor is indicated by not using the actor
        attribute (see section 4.2.2).

Specifically, to satisfy step 1 of the message exchange model,
one MUST parse the whole message (well, at least the Header and Body
since nothing is said about trailers), not just the headers because
of what is stated in section 4.3.1. Semantic equivalence means
(IMO) that a body entry that is not understood by the ultimate recipient
MUST be handled in the same manner as "header entries". Since there
can be more than one body entry, all must be inspected before
processing can be performed (again, based on a strict, literal,
interpretation of section 2). Again, I recognize that [2] suggests
that no current SOAP implementations do an mU check on Body, but that
doesn't make it correct. Section 4.3.1 must either be removed
or completely recast. I think that our spec needs to be
much clearer on handling of "you sent me this Body and I don't
get it" faults if they are indeed different than header mU faults.

We could separate out the Header and Body mU checks, but this
raises the same issues as with allowing for trailer mU checks
(should we allow for this) in a streamed processing model where
both the input message and "response" are streamed (e.g. output
is streamed as a *direct* result of streamed input processing)
because there is no mechanism for handling "oops!! nevermind,
I didn't understand the whole message...". What is also unclear
to me is how an application-level or for that matter parser-level
error (as in the case of a not-well-formed SOAP message) would be 
reported in a streamed processing model should one be encountered
as the message is being processed, regardless of whether or not
there was total understanding of the message or whether only the
Body element were being streamed.

In conclusion, I don't think that it is realistic to
expect that any purely or even partially streamed process
model can be supported without some provision for buffering
the "response" (or causally subsequent message) which
would seem to me to suggest that it *would* be practical
to support both Body and Trailer mU checks using the
algorithm that is suggested by Jacek in [1]:

>  Interleaving mU checks with processing (the first step being
> splitting mU checking into before-Headers and before-Body) could
> lead us to do the mU check on each single block only before
> processing each one of them. Something like:
> 
>  while(! bs.atEnd()) {
>     Block b=bs.next();
>     checkMU(b);
>     b.process(...);
>  };
> 

Note that this *does* provide for checking mU on trailers
*after* the body has been processed. In fact, the whole
algorithm, including mU faulting could be expressed as
(excuse my Java;-):

	ByteArrayOutputStream res = new ByteArrayOutputStream();
	try {
	  while(! bs.hasMoreElements()) {
	    Block b=(Block)bs.nextElement();
	    checkMU(b);
	    b.process(res, ...);
 	  }
	  req.send(res);
	} catch (Exception x) {
		req.fault(x);
	}

This requires that the text of section 2 (above) will require
modification to relax the required ordering currently specified
with a note that addresses the implications which captures
much of the discussion that this issue has raised especially
as regards to streamed processing of SOAP messages as well
as to highlight the potential need for (in certain, but certainly
not all, cases) rollback of partial processing in the face of
an exception. 

I believe that it also provides for equal and consistent
handling of header, body AND trailers whether they or not
any attempt is made to remove or recast the distinction between
header, body and trailer blocks.

Note that I don't believe that this approach impacts
backward compatibility, it just removes the required
ordering of:
	1) identify all headers [blocks] 
	2) verify mU on all
	3) process all

A possible revised section 2 might look like:

	A SOAP application receiving a SOAP message MUST process that 
	message by performing the following actions:

              1.Identify all parts of the SOAP message intended for that 
		application (see section 4.2.2) 
              2.For each mandatory part identified in step 1, verify that it is 
		supported by the application (see section
                4.2.3) and process accordingly. If this is not the 
		case then fault the message  as described in section 4.4. 
		The processor MAY ignore optional parts identified in step 1 without 
		affecting the outcome of the processing.
	...

Cheers,

Chris

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0111.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0113.html

Received on Wednesday, 13 June 2001 19:29:33 UTC