Re: Issue 25 Proposal

 Chris,

 I didn't mean that your simplification _is_ a mathematical
abstraction, it just feels like one. My point was that if the
average software architect tries to grasp your simplified SOAP,
they would get lost in the layering - where SOAP is
>>metadata in headers and data in the Body<<
the simplified SOAP is >>data in the blocks<<, on top of which
you have to layer some convention on where to put the data and
where to put the metadata.

 When I restated what you already said, I wanted to add one more
point against your simplified approach. The fault handling would
be much more complicated, which IMO would cause implementation to
be more complex rather than simpler.

 As for there being cases when you want to have a header even
considerably bigger than the body - I have two comments:

 1) by "the body is the only big thing" I didn't mean that the
body couldn't be small. I meant that if processing something is
going to cause you memory problems, it's going to be the body
rather than headers. In the digsig scenario nobody would go
streaming because there the secure auth is more important than
memory considerations.

 2) you can always shoot yourself in the foot. 8-)

 I wouldn't think of my assumptions as assumptions, I would
rather state them as the target area for an XML protocol.

                            Jacek Kopecky
                               Idoox



On Mon, 11 Jun 2001, christopher ferris wrote:

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

Received on Tuesday, 12 June 2001 04:28:00 UTC