W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2003

Streaming and Well-Formedness

From: Noah Mendelsohn/Cambridge/IBM <noah_mendelsohn@us.ibm.com>
Date: Mon, 31 Mar 2003 20:50:54 -0500
To: xml-dist-app@w3.org
Message-ID: <OF4A23D159.2D105905-ON85256CFB.0009E8A0@lotus.com>





A recent internal discussion at IBM has led me to question the degree to
which SOAP is amendable to streaming.  On the one hand, we know that our
mustUnderstand rules tend to preclude streaming until at least the start of
the body, but I had more or less assumed that we would allow for streaming
past that, and indeed I believe that in the description of the
Request/Response pattern [1] we specifically allow for this by saying:

-----------------------
Bindings that implement this MEP MAY provide for streaming of SOAP
responses. That is, responding SOAP nodes MAY begin transmission of a SOAP
response while a SOAP request is still being received and processed. When
SOAP nodes implement bindings that support streaming, the following rules
apply:

* All the rules in [SOAP Part 1] Binding Framework regarding streaming of
individual SOAP messages MUST be obeyed for both request and response SOAP
messages.

* When using streaming SOAP bindings, requesting SOAP nodes MUST avoid
deadlock by accepting and if necessary processing SOAP response information
while the SOAP request is being transmitted.

--Note:

--Depending on the implementation used and the size of the messages
involved, this rule MAY require that SOAP applications stream
application-level response processing in parallel with request generation.

* A requesting SOAP node MAY enter the "Fail" state, and thus abort
transmission of the outbound SOAP request, based on information contained
in an incoming streamed SOAP response.
-----------------------
The referenced section in part 1 says [2]:

-----------------------
Bindings MAY provide for streaming when processing messages. That is, SOAP
nodes MAY begin processing a received SOAP message as soon as the necessary
information is available. SOAP processing is specified in terms of SOAP
message infosets (see 5. SOAP Message Construct). Although streaming SOAP
receivers will acquire such XML infosets incrementally, SOAP processing
MUST yield results identical to those that would have been achieved if the
entire SOAP envelope were available prior to the start of processing. For
example, as provided in 2.6 Processing SOAP Messages, identification of
targeted SOAP header blocks, and checking of all mustUnderstand attributes
is to be done before successful processing can proceed. Depending on the
representation used for the XML infoset, and the order in which it is
transmitted, this rule might limit the degree to which streaming can be
achieved.
-----------------------

That all makes sense, except for one thing.  When using the obvious XML 1.0
serialization as in the HTTP binding, we do not even know that the XML is
well formed until the end.

So my question:  other than the usual provision that allows for rollback
etc., do we in fact support any form of streaming when using the HTTP
binding (or any other XML 1.0 serialization)?  Seems to me the rules above
preclude it.   Once we start to do useful application processing, we can't
send a fault, particularly if we have started to stream a response while
the request is still coming in as signaled in [1].   Is this old news?  I
guess I sort of knew it in the back of my mind all along, but this is the
first time I've really thought through the implications.  Am I missing
something? Thanks.


[1] http://www.w3.org/TR/2002/CR-soap12-part2-20021219/#bindformdesc
[2] http://www.w3.org/TR/2002/CR-soap12-part1-20021219/#bindfw

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------
Received on Monday, 31 March 2003 20:57:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:13 GMT