Re: ordering

Mark,

I think properties should be modeled at the level to which they pertain,
and since the abstract level does optimize elements, it should have a
property listing them; and since the implementation level creates parts,
it can have a property specifying the order of the parts. 

On the abstract level though, the elements that are being optimized are
already in an order (XML document order), and that doesn't change in
this layer, I refuse the idea of an abstract-level ordering property,
because we'd have to expand the abstract feature in order to be able to
accommodate the ordering property, and I don't think that expansion (or
that property) is required.

Best regards,

                   Jacek Kopecky

                   Senior Architect
                   Systinet Corporation
                   http://www.systinet.com/





On Thu, 2003-07-17 at 23:56, Mark Nottingham wrote:
> 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 Friday, 18 July 2003 11:49:25 UTC