- From: Herve Ruellan <ruellan@crf.canon.fr>
- Date: Tue, 12 Jun 2001 15:38:02 +0200
- To: Jacek Kopecky <jacek@idoox.com>
- CC: xml-dist-app@w3.org
Jacek, I interleaved my comments. Jacek Kopecky wrote: > > [ snip ] > > Please, can you show me the specific problems created by > separation of Headers and Body? First, I think that both headers and body are blocks, but separating them enforce to process them separately. Second, there are several use cases where it is needed to have a header after the body (that is a block containing metadata like a checksum after the block containing the application message). To handle such use cases we have either to rely on tricks (putting the application message in a header and having the body refer to it) or to introduce trailers which may or may not be fully- fledged blocks. Third, having only one block for the body do not allow us to send multiple application messages in one SOAP message to a given target. This may be useful for some applications (for example, I would be able to tell my bank in one SOAP message that I want to buy Canon stocks and sell France-Telecom stocks). > If we disallow XMLP blocks after the Body I think that this > separation divides the message in a meaningful way. In some cases > though we'd like to carry some metadata _after_ the body, if only > in some special cases (the use of trailers should be > discouraged). We won't add XMLP blocks after the body so no more > handling complexity comes in, we just add plain old addressable > data. I think we have to provide trailers, because some users will need them. And I think those trailers will add complexity both to the specification (we can already see it in the thread at [1] discussing about their definition) and to the way messages are processed (senders must be able to add trailers, receivers to access them...). > [ snip ] > > But SOAP already know how to address blocks to different > endpoints. I am not sure we agree or disagree on this as we may have different definition for 'endpoints'. So I would rather say that SOAP knows how to send blocks targeted at different handlers located on the same destination node. > I think that if you want to have several application-level > messages directed to one endpoint and with the same handling on > the part of the SOAP processor, it can easily be viewed as having > one larger application-level message. This message is divided (at > the application level) but the SOAP processor needn't be > concerned with this. I agree that it could be done, but at the cost of more processing at the application level. Whereas if we have blocks, the SOAP processor will have a dispatching mechanism able to direct each block to the right handler. In this way, your application will receive each application-level message separately and will not have to split a larger application-level message into its sub-components. Furthermore, I think it is easier for an application to say 'you can send me StockQuote, StockSell and StockPurchase messages' rather that say 'you can send me StockQuote, StockSell and StockPurchase messages and also StockProcessing messages which can contain any combination of the former ones'. Best regards, Hervé. [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0084.html
Received on Tuesday, 12 June 2001 09:40:03 UTC