Describing which blobs are to be optimized.

The WS Description WG is working through an issue (#207 [1]), which is
XOP-related.  As we communicated to you earlier [2], the ability of a
service to accept and transmit XOP can be indicated by indicating the
HTTP Transmission Optimization Feature is in use through the WSDL
feature syntax.  This syntax also allows the MTOM feature to be
"required", which we interpret as, the service must be sent a XOP
envelope and media type, though XOP itself doesn't constrain which parts
of the XML within that envelope have been optimized (it could be none).

A question arises ([3] continuing on [4]) that if XOP is required,
whether it further makes sense to say precisely which parts of the
message are to be optimized.  As we understand it, this allows a service
to place additional restrictions on the use of XOP beyond what the XOP
spec describes, but not leaving it completely up to the application
layer.  These additional restrictions could be along the lines of
"anything marked with an expectedMediaType attribute must be optimized",
to a fine level of granularity through an xop:optimize="true" attribute
on the schema.

The working group has a preference (straw poll 7 to 4 [5]) to indicate
in some fashion which parts must be optimized.  However, since you own
the HTTP Transmission Optimization Feature, we wanted to ask you two
questions:

1) Do you feel that such descriptive hints would be useful or is it
contrary to the expected usage patterns of XOP?
2) If it is useful, would you be willing to describe these hints,
including introducing syntax, in the MTOM or XOP specs?  (Splitting a
feature and it's descriptive hints across multiple specs seems
suboptimal to us.)

[1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x207
[2] http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0077.html
[3] http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0089.html
[4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0000.html
[5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0019.html

Received on Friday, 4 June 2004 14:26:57 UTC