- From: Herve Ruellan <ruellan@crf.canon.fr>
- Date: Tue, 12 Jun 2001 10:16:06 +0200
- To: Jacek Kopecky <jacek@idoox.com>
- CC: xml-dist-app@w3.org
Jacek, My comments are interleaved. Jacek Kopecky wrote: > > Hi, please see my post re: 'Issue 25 Proposals from the f2f' > first. > > Christopher, there has been agreement on first checking for mU > faults and only when every header is known to be known to the > processor can the processing begin. > > I agree that your approach would be a simplification, but only > for those who don't mind mathematical abstractions. Sometimes a > little bit of additional complexity adds a lot to clarity of the > purpose. That's one point for keeping Body separate. Whereas Chris' approach is different and enforce us to readjust our way of thinking about SOAP messages, I don't think it is harder to understand. However, I am afraid that the current state of SOAP with a separate Body may lead us to add much more complexity to solve specific problems created by separation of Headers and Body. In particular, I think that handling trailers will add complexity to this approach. > Your simpler approach also completely kills the possibility of > streaming, which is arguably a useful optimization. Why can't you > stream any more? Because you have to see the end tag > (</SOAP:Envelope> in your case) before being sure that you will > understand all the headers - that's because only the ending > SOAP:Envelope tag tells you there is no more SOAP:Block. > > If we had SOAP:Header, SOAP:Body and SOAP:Trailer (the last > with the same handling rules as the first) with sequential mU > checking and processing, we could encounter a situation where the > body has been processed successfully but then you don't > understand one of the mU trailers. > > As for why streaming only the Body seems sufficient to me: I > have an opinion and a feeling that headers are going to be used > for relatively small metadata only. Then the body can bear the > bulk of the data and streaming can be more important to you than > knowing beforehand the data is proper XML. If encountering a > parser error mid-stream would cause you a head-ache, you wouldn't > even consider streaming. On the other hand when memory is limited > and where rollback is either simple or unnecessary altogether, > you'll be glad if you know "from now on I can stream if I will". I think that even with the current SOAP specification, there will be may case when streaming will not be allowed. If you have a header containing a digital signature of the body that requires you to check the content of the body, you would have to parse the body while processing this header. > Even in messaging environments, where you argue your simpler > approach "might prove quite valuable", I think I have reasons why > Body is special: > > I'd naturally map one SOAP message to one application-level > message. This application-level message would live in the Body, > possibly decorated with headers. > > If you kept your simple model with only Blocks, you could easily > start putting more application-level messages into one SOAP > message, then the next simple step is to address these to > different endpoints, and what you end up with is a bus structure > with complex semantics due to its immense flexibility. I wouldn't > like to go there. I think that putting several application-level messages into one SOAP message is very handy. However, I think that addressing them to different endpoints is a very big change to the purpose of SOAP. I don't think we should address this problem in SOAP. > > Best regards > > Jacek Kopecky > Idoox > Regards, Hervé.
Received on Tuesday, 12 June 2001 04:18:10 UTC