W3C home > Mailing lists > Public > xml-dist-app@w3.org > June 2001

Re: Issue 25 Proposal

From: Herve Ruellan <ruellan@crf.canon.fr>
Date: Tue, 12 Jun 2001 10:16:06 +0200
Message-ID: <3B25CFC6.A6A1E280@crf.canon.fr>
To: Jacek Kopecky <jacek@idoox.com>
CC: xml-dist-app@w3.org

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


Received on Tuesday, 12 June 2001 04:18:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:36 UTC