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

Re: Issue 25 Proposal

From: christopher ferris <chris.ferris@east.sun.com>
Date: Mon, 11 Jun 2001 18:34:59 -0400
Message-ID: <3B254793.CB69916F@east.sun.com>
To: Jacek Kopecky <jacek@idoox.com>
CC: xml-dist-app@w3.org

Please see below.



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

>  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".
Received on Monday, 11 June 2001 18:36:59 UTC

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