Re: PASWA Feature Descriptions

Noah,

My reply to your comments is interspersed below.

Hervé.

Mark Nottingham wrote:

<snip/>
> 
> Additionally, Noah has made some recent comments against this draft that
> have yet to be incorporated. Rather than delay the distribution to the WG,
> I've appended them here:
> 
> * suggest:  "The Abstract Inclusion Feature enables SOAP applications to
> optimize" -> "The Abstract Inclusion Feature enables SOAP bindings to
> optimize "

OK.

> * 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).

> * 2.4.2: "The SOAP node binding MUST reconstruct the original SOAP message
> infoset." suggest -> "The 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."

Agreed, this is far better.

> * 2.4.1 and 2,4,3:  both of these say that we MUST apply a set of rules,
> all of which are SHOULDs or MAYs.  Not sure whether that's the best we to
> present it.

I'm not fully satisfied with the current presentation of the rules. I 
think that removing the list presentation in 2.4.1, 2.4.2 and 2.4.3 and 
rewriting a paragraph for each rule may be the best thing to do (all the 
more as probably some of the rules will be expanded to be made more 
clear/precise).

> * 3.1 Spelling error:  " Introeiisduction" -> "Introduction"

Should have been a funny cut and paste error :-).

> 
> I think the HTTP binding is good, at least as a starting point for
> discussion, but I suggest that we need to deal with two details (at
> least):

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 think we need to indicate that in all other respects, the binding
> follows the rules of the existing HTTP binding.

Yes.

> * 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.

> 
> --
> Mark Nottingham
> 
>

Received on Wednesday, 11 June 2003 04:26:09 UTC