Re: Optimization Mechanism description (was PASWA Feature Description)

[[[
Do we allow the optimization of only base64 binary content or do we allow
to generalize the aof:OptimizationCandidates as a list of (type,
elementID) pairs? This would allow for binary transmission of integers,
floats, and so on.
]]]

I think this it is necessary and desirable to allow different types of
encodings, especially in the abstract feature. This would allow new
encodings - for example, you could attach a plain XML document but have it
surfaced in the Infoset as entity-encoded text. The cost of extensibility
here is low.

Also, I assume you don't mean elementID as in id="" - rather just tuples
of (type, node).


----- Original Message ----- 
From: "Herve Ruellan" <herve.ruellan@crf.canon.fr>
To: "XMLP Dist App" <xml-dist-app@w3.org>
Sent: Wednesday, June 18, 2003 8:01 AM
Subject: Optimization Mechanism description (was PASWA Feature
Description)


Dear all,

Here is a new draft of the Optimization Mechanism (renamed from
Inclusion Mechanism).
It includes the modifications suggested during last week (11/6/03)
telcon, as well as Noah's and Mark's suggestions.

For better finding what's new in it, it has colored diffs and has an
history log at the end.

Hervé.



--------------------------------------------------------------------------
------


Optimization MechanismOptimization Mechanism
W3C Working Draft 18 May 2003
Copyright © 2003 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C
liability, trademark, document use, and software licensing rules apply.


--------------------------------------------------------------------------
------

Abstract
This document describes an abstract feature and a concrete implementation
of it for optimizing the transmission and/or wire format of SOAP messages.

Status of this Document
This document is an editors' copy that has no official standing.

This document is a working draft.


--------------------------------------------------------------------------
------

Short Table of Contents
1. Introduction
2. Abstract Optimization Feature
3. HTTP Optimization Feature
A. History



--------------------------------------------------------------------------
------

Table of Contents
1. Introduction
2. Abstract Optimization Feature
    2.1 Introduction
    2.2 Abstract Optimization Feature Name
    2.3 Abstract Optimization Feature Properties
    2.4 Abstract Optimization Feature Processing
        2.4.1 Sending a message
        2.4.2 Receiving a message
        2.4.3 Transmitting a message
3. HTTP Optimization Feature
    3.1 Introduction
    3.2 HTTP Optimization Feature Name
    3.3 Implementation
        3.3.1 Include element
        3.3.2 href attribute
        3.3.3 Sending a SOAP message
        3.3.4 Receiving a SOAP message


Appendix
A. History
    A.1 18 May 2003



--------------------------------------------------------------------------
------

1. Introduction
The first part of this document (2. Abstract 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.

This abstract feature is intended to be implemented by SOAP bindings,
however nothing precludes from implementing it as a SOAP module. In a
second part (3. HTTP Optimization Feature), this document describes such
an implementation for an HTTP binding.

      Editorial note: HR
      Is the new name better?

2. Abstract Optimization Feature
2.1 Introduction
The Abstract Optimization Feature enables SOAP bindings to optimize the
transmission and/or wire format of a SOAP message by selectively
re-encoding portions of the message, whilst still presenting an XML
Infoset to the SOAP application.

The Abstract Optimization Feature also enables SOAP applications to
provide hints about what part of a SOAP message could be re-encoded in an
efficient way. However, it is up to the implementation to decide if and
how it will optimize the transmission of a given SOAP message.

2.2 Abstract Optimization Feature Name
This Abstract Optimization Feature is identified by the URI:

  a.. "http://www.w3.org/2003/06/soap/features/abstract-optimization".

2.3 Abstract Optimization Feature Properties
The Abstract Optimization Feature defines a set of properties described in
Table 1.

  Table 1: Property definition for the Abstract Optimization Feature
Property Name Property Description
      aof:OptimizationCandidates  A List containing zero or more (pointers
to) element information items within the SOAP envelope candidate for being
transmitted in an optimized way. The manner in which such identification
is represented in the node is at the discretion of the implementation.

Note: Among the possible choices for identifying element information items
in the aof:OptimizationCandidates are XPaths relative to the Envelope
element, or pointers to the internal implementation of the elements in
question. Indeed the list may be implicit in the content of the envelope
itself. For example, any information item with contents that happen to be
the canonical form of some base64 binary value can be implicitly included
in the list if desired.

      Editorial note: HR
      Does "enabling" an Abstract Feature make sense for a SOAP node? If
this is not the case, another property should be created for reflecting
the fact that the Abstract Optimization Feature is enabled or not.
      Editorial note: HR per Noah's remark
      Do we allow the optimization of only base64 binary content or do we
allow to generalize the aof:OptimizationCandidates as a list of (type,
elementID) pairs? This would allow for binary transmission of integers,
floats, and so on.

2.4 Abstract Optimization Feature Processing
2.4.1 Sending a message
To send a SOAP message using the Abstract Optimization Feature, an
application MUST enable the Abstract Optimization Feature. In addition it
SHOULD define the value of the aof:OptimizationCandidates property.

When sending a SOAP message with the Abstract Optimization Feature
enabled, a SOAP node using a binding implementing the Abstract
Optimization Feature SHOULD optimize the transmission of all the SOAP
message element information items listed in the value of the
aof:OptimizationCandidates property.

In addition, the SOAP node binding MAY optimize the transmission of other
SOAP message element information items not listed in the value of the
aof:OptimizationCandidates property. In particular, if the
aof:OptimizationCandidates property is not defined or if it has an empty
value, the SOAP node binding MAY optimize the transmission of any SOAP
message element information item.

      Editorial note: HR
      Do we allow the optimization of the Envelope, Header, Body element
information items, or of a full Header Block?
      Editorial note: HR
      If the binding used does not implement the Abstract Optimization
Feature there are several options which can be followed: fault; send the
message ignoring the request for using the Abstract Optimization Feature;
send the message including the request for using the Abstract Optimization
Feature (allows an intermediary implementing it to use its
implementation).

2.4.2 Receiving a message
When receiving a SOAP message using an implementation of the Abstract
Optimization Feature, a SOAP node MUST fault if it does not support the
implementation used or the Abstract Optimization Feature.

When receiving a SOAP message using an implementation of the Abstract
Optimization Feature, a SOAP node binding MUST be capable of
reconstructing the original SOAP message infoset. However, implementations
are free to reconstruct only those portions actually needed for
processing, or to present information from the message in a form
convenient for efficient processing. For example, a value sent in an
optimized form (e.g. binary) MAY be made available in that form as well as
in the character form mandated by the Infoset.

When receiving a SOAP message using an implementation of the Abstract
Optimization Feature, a SOAP node binding MUST enable the Abstract
Optimization Feature. In addition, the SOAP node binding SHOULD/MAY set
the value of the aof:OptimizationCandidates property to reflect the SOAP
message parts whose transmission was optimized in the incoming message.

      Editorial note: HR
      We should decide on a SHOULD or on a MAY. In addition, the
aof:OptimizationCandidates property is not very meaningful on the receiver
side. We may create another property for reflecting element information
items whose transmission was effectively optimized (an efficient
implementation will provide this property to allow efficient retrieval of
the optimized element information items).

2.4.3 Transmitting a message
The usage of the Abstract Optimization Feature is a hop by hop contract
between a SOAP node and the next SOAP node in the SOAP message path.
Therefore, no specific rules exist for a SOAP intermediary implementing
the Abstract Optimization Feature.

However a SOAP intermediary implementing the Abstract Optimization Feature
MUST still follow the rules related to the usage of an implementation of
the Abstract Optimization Feature when receiving the message (see 2.4.2
Receiving a message) and those related to the usage of an implementation
of the Abstract Optimization Feature when sending the message (see 2.4.1
Sending a message). In addition, it MUST follow the rules for relaying
SOAP messages (see [W3C.soap-part1] Relaying SOAP Messages).

3. HTTP Optimization Feature
3.1 Introduction
The HTTP Optimization Feature is a binding level feature, implementing the
Abstract Optimization Feature in an HTTP binding.

This HTTP Optimization Feature builds upon the current HTTP binding (see
[W3C.soap-part2] /SOAP HTTP Binding), enhancing it with the support of the
Abstract Optimization Feature. In all aspects not described in this
section, the rules of the HTTP binding are not modified.

3.2 HTTP Optimization Feature Name
This HTTP Optimization Feature is identified by the URI:

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

3.3 Implementation
3.3.1 Include element
The Include element information item is used by the HTTP Optimization
Feature for replacing optimized element information items while still
preserving the logical link between the SOAP message infoset and the
optimized data. To reconstruct the original infoset, an Include element
information item should be logically replaced by the base64 encoded value
of the data referred to in its href attribute information item.

The Include element information item has:

  a.. A [local name] of Include .

  b.. A [namespace name] of
"http://www.w3.org/2003/06/soap/features/http-optimization".

  c.. Zero element information item in its [children] property.

  d.. One or more attribute information items in its [attributes]
property. Among these MUST be the following:

    a.. href attribute information item (see 3.3.2 href attribute).

3.3.2 href attribute
The href attribute information item is used to refer the optimized form of
the data replaced by the Include element information item containing it.

The href attribute information item has the following XML infoset
properties:

  a.. A [local name] of href .

  b.. A [namespace name] which has no value.

  c.. A [specified] property with a value of "true".

The type of the href attribute information item is xs:anyURI. The value of
the href attribute information item is a URI that refers to an optimized
form of the element information item replaced by the Include element
information item containing it.

3.3.3 Sending a SOAP message
When sending a SOAP message for which the Abstract Optimization Feature is
enabled, the HTTP Optimization Feature optimizes the transmission of the
message by transmitting in a compact form parts of the SOAP message. The
SOAP message is serialized into a MIME multipart (ref) packaging, one body
part, the root object, being an XML representation of the SOAP envelope,
while other body parts contains the parts of the SOAP message transmitted
in a compact form.

The HTTP Optimization Feature affects the serialization of the SOAP
message infoset into the HTTP body. Unless otherwise stated, serializing a
SOAP message infoset into the HTTP body MUST be semantically equivalent to
performing the following steps separately, and in the order given.

  1.. Create a MIME multipart packaging to be serialized into the HTTP
body.

  2.. Create a list of the element information items whose transmission is
to be optimized. This list SHOULD contain all the element information
items of the SOAP message pointed to in the aof:OptimizationCandidates
property. This list MAY contain other element information items of the
SOAP message.

        Editorial note: HR
        Do we handle overlapping element information items?

  3.. Add a serialization of each element information item in the list in
a body part of the MIME multipart packaging.

        Editorial note: HR
        How do we set the Content-type?

  4.. Modify the SOAP message infoset by replacing each element
information item in the list by an httpo:Include element information item
referring to the body part of the MIME multipart packaging containing its
serialization.

  5.. Serialize the resulting SOAP message infoset, using XML 1.0, in the
root object of the MIME multipart packaging.

        Editorial note: HR
        Do we allow only an XML 1.0 serialization?

  6.. Serialize the MIME multipart packaging into the HTTP body.

3.3.4 Receiving a SOAP message
When receiving a SOAP message using the HTTP Optimization Feature, the
HTTP binding MUST, at least logically, provide an access to the
reconstructed SOAP message infoset.

The reconstruction of the SOAP message infoset from the data contained in
the HTTP Body MUST be semantically equivalent to performing the following
steps separately, and in the order given.

  a.. Extract the MIME multipart packaging from the HTTP body.

  b.. Extract the SOAP message from the root object of the MIME multipart
packaging and deserialize it to an infoset representation.

  c.. Extract and deserialize each other body part of the MIME multipart
packaging.

  d.. Find every httpo:Include element information item in the SOAP
message infoset.

  For each httpo:Include element information item, find the body part of
the MIME multipart packaging which is referred to by the href attribute
information item of the httpo:Include element information item. Replace
the httpo:Include element information item by the base64 encoded value of
the referred to body part.

When reconstructing a SOAP message infoset, the HTTP binding:

  a.. SHOULD generate an "env:Sender" SOAP fault with a subcode of
httpo:MissingHRef if an httpo:Include element information item does not
contain a href attribute information item.

  b.. SHOULD generate an "env:Sender" SOAP fault with a subcode of
httpo:NotFoundHRef if not body part of the MIME multipart packaging
matches the href attribute information item of an httpo:Include element
information item.

      Editorial note: HR
      No more DoInclude header. The functionality should be transferred to
the SOAP Extensible HTTP Binding.

A. History
A.1 18 May 2003
  a.. Changed document's name from "Inclusion Mechanism" to "Optimization
Mechanism", and changed abstract feature name and HTTP feature name.

  b.. Corrected typos and other editorial errors.

  c.. Added a publication date.

  d.. Added an abstract.

  e.. Improved general introduction (1. Introduction).

  f.. Changed the presentation of the processing rules in 2.4.1 Sending a
message, 2.4.2 Receiving a message.

  g.. Shortened 2.4.3 Transmitting a message.

  h.. Improved HTTP implementation introduction (3.1 Introduction).

  i.. Added a description of the Include element information item and of
the href attribute information item.

  j.. Changed the presentation for sending a SOAP message through the HTTP
binding.

  k.. Improved the presentation for receiving a SOAP message through the
HTTP binding.

Received on Wednesday, 18 June 2003 18:52:41 UTC