W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2003

Re: ordering

From: Mark Nottingham <mark.nottingham@bea.com>
Date: Thu, 17 Jul 2003 14:56:22 -0700
Cc: Christopher Ferris <chrisfer@us.ibm.com>, Marc Hadley <marc.hadley@sun.com>, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
To: Jacek Kopecky <jacek@systinet.com>
Message-Id: <80DD971B-B8A1-11D7-B38C-00039396E15A@bea.com>

I don't think we disagree; I was arguing that ordering needs to be 
considered, not at what level. It would be odd, however, if we were to 
abstractly model one property but not another for reuse.

Even if we did model ordering as an abstract-level property, 
implementations that don't offer it could simply not use that property.

Cheers,


On Thursday, July 17, 2003, at 01:18 AM, Jacek Kopecky wrote:

> Mark,
>
> as the abstract optimization feature doesn't speak about what the
> optimization is going to be, and specifically it doesn't speak about 
> any
> kind of splitting of the Envelope into different parts, it should not
> try and provide for ordering of those.
> The concrete implementation can have properties like ordering if we 
> find
> it useful. But the abstract feature and its processing described in
> section 2 should not be affected.
>
> To illustrate an implementation that does not introduce ordering, let 
> me
> mention again a possible optimization of the transmission of blocks of
> the SOAP messages by compressing them (likely very effective on XML, 
> say
> 70% decrease in size) and putting the result as base64 (33% increase in
> size) back in the message, which would mean 60% decrease in size of
> transferred XML data. As all stays in the envelope and in the same
> order, there are no parts that could be reordered.
Received on Thursday, 17 July 2003 17:56:36 GMT

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