Re: ordering

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 UTC