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

Re: Issue 25 Proposal

From: Jacek Kopecky <jacek@idoox.com>
Date: Wed, 13 Jun 2001 22:44:32 +0200 (CEST)
To: Jean-Jacques Moreau <moreau@crf.canon.fr>
cc: Herve Ruellan <ruellan@crf.canon.fr>, <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0106132204340.22959-100000@bimbo.in.idoox.com>
 Jean-Jacques,

 I understand what you mean but I don't think you've shown any
problems.

 Please let me now show you a little exercise - every paragraph
is meant as a simple step from the previous, every paragraph is
also meant as an atomic point where I'd like you to say "Here I
don't agree." If you aren't interested in the exercise you can
skip until 'Here things start getting real again'.

 We have your choices A and B and nothing more.

 B can be rewritten as A if we choose any header as the body.

 Since the thinking now is that mustUnderstand check precedes any
processing in the current block of blocks (Headers, Body,
Trailers or Blocks), we can insert the commands
checkMU(hs);checkMU(b);checkMU(ts); or the command checkMU(bs);
before the first while loop and both cases would still be
equivalent.

 Now what I think the separation of headers and body (and
possibly trailers) can bring us is spreading the three checkMUs
in A:
 checkMU(hs);
 while(...) hs.next().process(...);
 checkMU(b);
 b.process(...);
 checkMU(ts);
 while(...) ts.next().process(...);

 Because checkMU(set) requires the set to be known (i.e. read
into memory at least until the first opening tag of the last
block), we can now spread the processing.

 Here things start getting real again.

 Interleaving mU checks with processing (the first step being
splitting mU checking into before-Headers and before-Body) could
lead us to do the mU check on each single block only before
processing each one of them. Something like:

 while(! bs.atEnd()) {
    Block b=bs.next();
    checkMU(b);
    b.process(...);
 };

 I'd agree with such a model although it would place a lot of
ordering burden on the sender or some tricks would have to be
played, for example inserting dummy mU headers at the front of
the message so that mU faults come back first.

 If we don't/can't agree on such a model, I think at least
checking mU on trailers would need to be done _after_ processing
the body in order to keep some streamability; but this feels
wrong as you could get an mU fault from a message whose body (the
flesh) was successfully processed.

 Regards


Jacek Kopecky

Idoox
http://www.idoox.com/



On Tue, 12 Jun 2001, Jean-Jacques Moreau wrote:

 > Jacek Kopecky wrote:
 >
 > > Please, can you show me the specific problems created by
 > > separation of Headers and Body? [...]
 >
 > I think it ultimately boils down to choosing between option A or B below.
 >
 > A
 > =
 >     Envelope process() {
 >         Headers hs = headers();
 >         Body b = body();
 >         Trailers ts = trailers();
 >
 >         while (! hs.atEnd()) {
 >             Header h = hs.next();
 >             h.process(hs, b, ts);
 >         }
 >         b.process(hs, b, ts);
 >         while (! ts.atEnd()) {
 >             Trailer t = ts.next();
 >             t.process(hs, b, ts);
 >         }
 >     }
 >
 > B
 > =
 >     Envelope process() {
 >         Blocks bs = blocks();
 >
 >         while (! bs.atEnd()) {
 >             Block b = bs.next();
 >             b.process(bs);
 >         }
 >     }
 >
 > Jean-Jacques.
 >
 >
Received on Wednesday, 13 June 2001 16:44:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:01 GMT