MTOM Issue: Merge 'Abstract' and 'HTTP' feature URIs?

Based on the examples in the SOAP 1.2 Part 2 Recommendation [1] and
the SOAP 1.2 Attachments Note [2], it seems unnecessary to have
separate URIs for the abstract optimization feature and for its
implementation in a HTTP binding.

The "Introduction" section of MTOM [3] begins:

   The first part of this document (2. Abstract Transmission
   Optimization Feature) describes an abstract feature for optimizing
   the transmission and/or wire format of a SOAP message by
   selectively re-encoding portions of the message, while still
   presenting an XML Infoset to the SOAP application.

and the fourth paragraph of the Introduction contains:

   The third part (4. HTTP Transmission Optimization Feature) uses
   this Inclusion Mechanism for implementing the Abstract Transmission
   Optimization Feature for an HTTP binding.

Since the HTTP binding is introduced as implementing the abstract
feature, the feature should be renamed:

   http://www.w3.org/2003/06/soap/features/optimization

and the description of the HTTP binding should state that it
implements the abstract feature rather than defining another,
protocol-specific feature that is related to the abstract feature only
in the minds of people who have read the MTOM document.

The precedent from SOAP 1.2 Part 2 [1] is the MEPs and features and
their support in the HTTP binding.

It is hard to be more abstract than a message exchange pattern, yet
the URIs for the MEPs' feature names omit 'abstract'.  For example,
the definition of the SOAP Response MEP in Section 6.3 is described
as:

   The description is an abstract presentation of the operation of
   this MEP. It is not intended to describe a real implementation or
   to suggest how a real implementation should be structured.

The HTTP binding in Section 7 states the MEPs and features that must
be supported by an implementation -- without introducing new feature
URIs -- and Section 7.5, MEP Operation, "describes the MEP state
machine and its relation to the HTTP protocol." [5]

The WebMethod feature in Section 6.4 is also pretty abstract since it
simply constrains the behaviour of a binding, yet the HTTP binding
definition desribes the binding's behaviour instead of defining
another feature indicating its support for the abstract feature.

The precedent from the SOAP 1.2 Attachment Feature WD [2] comes from
the Introduction:

   The purpose of this specification is not to define an actual
   representation of SOAP attachments but rather to define an abstract
   SOAP 1.2 feature which can be used as the basis for defining SOAP
   bindings that support the transmission of messages with
   attachments. The feature describes characteristics common to all
   such implementations.

and Section 2:

    Protocol binding specifications can use this URI to declare their
    support for this feature and its associated semantics.

I consider that MTOM should define one URI for the feature and the
definition of the HTTP binding should just state that the binding must
implement the feature.

Regards,


Tony Graham
------------------------------------------------------------------------
XML Technology Center - Dublin
Sun Microsystems Ireland Ltd                       Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3            x(70)19708


[1] http://www.w3.org/TR/soap12-part2/
[2] http://www.w3.org/TR/soap12-af/
[3] http://www.w3.org/2000/xp/Group/3/06/Attachments/OptimizationMechanism.html
[4] http://www.w3.org/TR/soap12-part2/#soapresmep
[5] http://www.w3.org/TR/soap12-part2/#http-msgexop
[6] http://www.w3.org/TR/soap12-part2/#WebMethodFeature

Received on Friday, 18 July 2003 11:21:20 UTC