- From: Jacek Kopecky <jacek@idoox.com>
- Date: Sun, 17 Jun 2001 18:09:35 +0200 (CEST)
- To: Mark Jones <jones@research.att.com>
- cc: <marting@develop.com>, <xml-dist-app@w3.org>
Mark, Gudge, I think the con of going this route would be in putting too much ordering burden on the client. The pro of this route would be the clear streaming point. But then if we call it StuffYouMustUnderstand everybody would put the request body in this part and out goes streaming again. If we want to keep the possibility of streaming (which I'm not so convinced about any more) I think we only need to drop the remark that Body is semantically equivalent to a header with mustUnderstand="1" - we should disallow mustUnderstand on Body blocks (if there can be more then one*) at all. Then we say "processing of Body is done _after_ checks and processing on Header" and we're set. * - I haven't seen any resolution on whether the Body contains blocks or is a block yet. I always understood SOAP as though Body is a (one) block. Jacek Kopecky Idoox http://www.idoox.com/ P.S: I'm starting to prefer the way of disallowing streaming altogether and saying "put the bloody huge data in an attachment as that's where streaming errors won't affect the validity of the whole message". On Thu, 14 Jun 2001, Mark Jones wrote: > > Gudge, > > Your (first) proposal: > <env:Envelope xmlns:env='http://www.w3.org/2001/06/soap-envelope' > > <env:StuffYouMUstUnderstand> > <!-- Stuff the end point must understand goes here --> > </env:StuffYouMustUnderstand> > <!-- streaming point is now here --> > <env:Stuff> > <!-- Stuff you don't have to understand (including stuff referenced from > above) goes here --> > </env:Stuff> > </env:Envelope> > > was pretty much exactly what I had in mind: > > > We seem to flirt from time-to-time with eliminating the > > header/body/trailer distinction. Another possibility is to make a > > break with SOAP 1.1 syntax and simply have a set of blocks in which we > > syntactically distinguish a streaming point if so desired. This point > > is the point after which we guarantee not to place/find any additional > > mU=1 blocks. > > > So the question is -- what are the pros and cons of going this route? > > What does it break? > > What are the advantages (apart from unification of header/body/trailer > and establishing a streaming point)? > > --mark >
Received on Sunday, 17 June 2001 12:09:36 UTC