Re: Issue 25 Proposal

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