Re: Issue 25 Proposal

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