Re: PASWA Feature Descriptions

Some additional comments and responses to discussion;

After re-reading the document and comments to date, I agree that
'Inclusion' is a bad name for the abstract feature; it's a detail of the
implementation, rather than something that evokes the functionality
provided. My current favourite for a name would probably be "Selective
Optimisation," so that we'd have a "Selective Optimisation Feature" in
section two.

Section three describes a feature as well, but if I understand correctly,
will be transformed into a part of a new HTTP binding description that
implements the feature described in section two (with other potential
changes as well). If this is correct, I imagine it will cease to be called
a distinct feature and eventually live in a separate document, so that
we'll have a "Selective Optimisation Abstract Feature" document, and
another document describing the HTTP binding.

Thinking about that binding a bit more, my preference would be to make is
a successor to the current HTTP binding, and therfore NOT call out the
relationship to MIME or this feature in its title.

Also, in section two, there are several references to this being
implemented in a binding, as well as a statement that "This abstract
feature is intended to be implemented by SOAP bindings" in section one.
While I agree with and support our decision to make our concrete
implementation a binding, I don't see the utility in limiting the
*abstract* feature to a binding implementation, as there may eventually be
a SOAP header implementation that offers equivalent functionality. More to
the point, I think our design process would be much improved by imposing a
rigid separation between the abstract description and the implementation
details. As a result, I'd suggest we remove that sentence from section
one, and change references to binding implementation (usually, "SOAP node
binding") to a generic "implementations."

The InclusionList property (which, if the above is agreed to, might be
better named OptimisationCandidates) might be better explained as a list
of nodes/Information Items acting as a hint to sending and forwarding
implementations that need to understand where optimisations are to be
made. I agree with Noah's comment in the document that it would probably
be better to have a list of (node, optimisation type) candidates, so that
we can accommodate optimisations other than base64-to-binary, like XML
entity encoding, etc.

More inline below -

> > * section 2.4.2:  I think if the receiving binding doesn't recognize
the
> > feature it MUST fault (or else we leave it to the binding itself to
decide
> > when to continue,  not clear we need to say anything at all, as SOAP
> > itself mandates successful transmission of the Infoset or else a
> > binding-specific fault.)
>
> I think that at the level of the Abstract Inclusion Feature description,
> we may either say:
> - If the receiving binding doesn't recognize the feature it MUST fault.
> or:
> - Each implementation of the Abstract Inclusion Feature MUST ensure that
> the receiving binding will behave correctly (ie, the binding will
> transmit the Infoset to the SOAP node) and MUST specify how the
> receiving binding will handle errors (such as not recognizing the
feature).

I agree with Noah here; it seems like we're introducing the negotiation of
a binding through the presence of features, and I'm not sure that was our
intention. I'd rather remain silent and let binding negotiation mechanisms
be developed separately; I think that SOAP is clear in this regard.


> Yes, the HTTP binding needs more work. In particular, the group should
> decide how we include the HTTP feature implementation in an HTTP
> binding: do we write an extensible HTTP binding?

I'd like to see us write a revision of the HTTP binding that implements
this feature in addition to the functionality already described (which may
mean that it uses multiple content-types). It would be great if it could
also accommodate additional features in the future.


> > * I think we need to decide on how the binding signals on the wire
that
> > the feature is being used.
>
> Yes. There are two aspects for this problem:
> - The binding should signal another HTTP binding implementing the
> feature that it is in use in the message.
> - The binding should signal another HTTP binding *not* implementing the
> feature that it is in use in the message and that this receiving binding
> must not try to handle the message
>
> To solve this problem, either we can use a SOAP Header signaling that
> the feature is in use (however in the later case, this will not be the
> HTTP binding that will detect the unsupported feature, but the SOAP
> processing, and the HTTP binding may have some trouble recovering the
> SOAP message).
> Or we can create an HTTP header for signaling which HTTP binding
> features are used in a particular SOAP message transmitted over HTTP.
> This leads to writing an extensible HTTP binding.

I think I prefer the latter approach; features provided by bindings should
be reflected in the underlying protocol, not SOAP. We'll also need some
serialization of the InclusionList (or whatever it's called) property
defined.

Cheers,

Received on Wednesday, 11 June 2003 13:46:50 UTC