Re: Issue 25 Proposal

Jacek,

Please see below.

Cheers,

Chris

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.

I'm not sure I follow here. Where's the mathematical
abstraction?

> 
>  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.

I recognized and clearly cited this in my posting. 

> 
>  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

Then you obviously haven't seen a digital signature expressed as XML;-)
I think that we should avoid making an assumption such as this
because someone will undoubtedly find a use that will violate 
the assumption which could break things in quite wonderous ways.

> 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".
> 
<snip/>