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

Proposed resolutions for issues 432 and 435 (long)

From: Jacek Kopecky <jacek@systinet.com>
Date: 16 Jul 2003 23:20:01 +0200
To: XMLP Dist App <xml-dist-app@w3.org>
Message-Id: <1058390401.8989.592.camel@localhost>

Hi all, per my action item I hereby propose resolutions to issues 432
[1] and 435 [2]. 

The proposed resolution to 432 was discussed on today's telcon and there
was no push-back, but for issue 435 I propose two resolutions to choose
from, together with their pros and cons. The proposals for 435 depend on
the proposal for 432 being accepted.

[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x432
[2] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x435

The references to sections and tables etc. below are to the
member-private MTOM document [3], which is going public soon, I hope.

[3] http://www.w3.org/2000/xp/Group/3/06/Attachments/OptimizationMechanism.html


Summary and rationale for the following proposal fo 432:
The proposal changes the semantics of the single property of the
optimization feature to carry the list of the elements which are to be
optimized for transmission. Rationale: this list is certainly needed by
the concrete implementation in order to do the optimization; any further
information (like what the application thought could be optimized),
unless transferred with the message, is only an internal matter in the
sender. It is possible to add further properties whose values will be
transferred with the message, when we have the requirements to do so.

================= proposal for 432
1. Change the second paragraph of section 2.1 to read 

"The Abstract Transmission Optimization Feature also enables SOAP
senders to provide information about what part of a SOAP message should
be re-encoded in an efficient way."

2. In section 2.3  in Table 2, change the property name to
http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizedElements
and its description to

"A list containing zero or more (pointers to) element information items
within the SOAP envelope that are to be transmitted in an optimized way.
The manner in which such identification is represented in the node is at
the discretion of the implementation. In the rest of the document, the
property is referred to in short as mtom:OptimizedElements."

3. Update the note below Table 2 to match the new name.

4. Change section 2.4.1 to read:

"To send a SOAP message using the Abstract Transmission Optimization
Feature, an application MUST enable the Abstract Transmission
Optimization Feature. In addition, the application or the SOAP node
implementation SHOULD set the value of the mtom:OptimizedElements
property.

When sending a SOAP message with the Abstract Transmission Optimization
Feature enabled, a SOAP node using a binding implementing the Abstract
Transmission Optimization Feature MUST optimize the transmission of all
the SOAP message element information items listed in the value of the
mtom:OptimizedElements property."

Both editor's notes still apply.

5. In section 2.4.2 trim the last paragraph to read:

"When receiving a SOAP message using an implementation of the Abstract
Transmission Optimization Feature, a SOAP node binding MUST enable the
Abstract Transmission Optimization Feature."

6. Remove the ed-note in 2.4.2.
================= end of proposal for 432


Rationale for the proposed resolutions for issue 435: the receiver-side
binding clearly can tell which elements were optimized in the incoming
message. Therefore it may present this information to the layers above
the binding and to the application. 

The two resolutions vary in the approach to making this information
available:

Proposal A puts the list of the elements that were optimized in the
received message as the initial value of the mtom:OptimizedElements
property. Proposal B puts the information as the value of a new
mtom:ReceivedOptimizedElements property. The real difference between
these two proposals only shows on intermediaries.

Pros and cons of proposal A: the proposal makes it clear that an
intermediary that doesn't knowingly change the property will optimize
the same elements. The user of the property must be aware of the
possible changes to its value when an intermediary prepares the outgoing
message. The text must say though that the intermediary MAY change the
value.

Pros and cons of proposal B: the application has a clear place from
which to get the information on what was optimized and this value will
not change when the intermediary prepares the outgoing message. In case
we close the example subissue in issue 431 saying that intermediaries
should preserve what is being optimized, the resolution should make it
clear that we expect intermediaries at least to copy the value of the
mtom:ReceivedOptimizedElements property to the mtom:OptimizedElements
property, if the intermediaries don't want to interfere with the
selection of optimized elements.


================= proposal A for 435
1. In section 2.4.2 add a paragraph that reads:

"In addition, the SOAP node binding MUST set the value of the
mtom:OptimizedElements property to reflect the SOAP message parts whose
transmission was optimized in the incoming message."

2. In section 2.4.3 add a paragraph that reads:

"Note that unless the application or the SOAP intermediary
implementation changes the value of the property mtom:OptimizedElements
and if the Abstract Transmission Optimization Feature is enabled, the
same elements will be optimized in the outgoing message as were in the
received message.
================= end of proposal A



================= proposal B for 435
1. In section 2.3 in Table 2, add the property named
http://www.w3.org/2003/06/soap/features/abstract-optimization/ReceivedOptimizedElements
with the following description:

"A list containing zero or more (pointers to) element information items
within the SOAP envelope that were transmitted in an optimized way in
the received message. The manner in which such identification is
represented in the node is at the discretion of the implementation. In
the rest of the document, the property is referred to in short as
mtom:ReceivedOptimizedElements."

2. In section 2.4.2 add a paragraph that reads:

"In addition, the SOAP node binding MUST set the value of the
mtom:ReceivedOptimizedElements property to reflect the SOAP message
parts whose transmission was optimized in the received message."
================= end of proposal B


I think that's it. 8-)

Best regards,

                   Jacek Kopecky

                   Senior Architect
                   Systinet Corporation
                   http://www.systinet.com/
Received on Wednesday, 16 July 2003 17:20:06 GMT

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