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

+1

----- Original Message ----- 
From: "Tony Graham" <Tony.Graham@Sun.COM>
To: "Xml-Dist-App" <xml-dist-app@w3.org>
Sent: Friday, July 18, 2003 8:23 AM
Subject: 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 14:36:32 UTC