Re: Allowed top-level elements

[Christine Tomlinson <chris.tomlinson@sun.com>]

In the context of the SOAP binding I agree that a <batch:request>
must be allowed.

I agree that a client should be permitted to send zero, one or more requests in a <batch:request> (although I'm not sure of the intent of zero other than perhaps allowing a client to not make a test as to whether that case occurred). The SOAP binding proposal that was sent out 8/17 didn't preclude this.

The concrete reasons for permitting single operations or alternatively not mandating the exclusive use of the <batch:request> are:

1) <batch:request> as defined is inappropriate or unneeded in at least 3 reasonable bindings/applications of DSMLv2: a) transactions; b) message busses; and c) high-latency scripted DSMLv2 services.
2) It is not inherently complex to allow a client and require a server to handle single operations without using a <batch:request>.

It is appropriate that we define DSMLv2 so that there is a core that is binding independent and that we define at least the SOAP and file bindings as normative in DSMLv2. We do not see a benefit to DSMLv2 that it be a requirement that the core include <batch:...> as mandatory in all bindings that may be defined in order for the binding to be considered a valid DSMLv2 binding.

ciao,
Christine
 

Jeff Parham wrote:

>  One
> of the open issues with respect to DSMLv2 is which elements are allowed
> to be top-level elements in a DSML request.  The dsmlEnvelopeRequest
> must be allowed as a top-level element in order to support multiple operations
> per request -- the question is whether additionally to allow individual
> operations (searchRequest, addRequest, etc.) to be expressed as top-level
> elements without a surrounding dsmlEnvelopeRequest.According
> to section 4 of the initial draft of the specification, any implementation
> that supports dsmlEnvelopeRequest must support zero, one, or many requests
> per envelope.  This makes sense to me -- I wouldn't want to see us
> force some client that typically uses a dsmlEnvelopeRequest top-level element
> to switch to a different top-level element if it happened to have only
> one request to send, for example.Thus
> any DSML implementation that supports batching must already support one
> form of single-element requests -- a single-request dsmlEnvelopeRequest. 
> The question then boils down to what advantages there would be to allowing
> the envelope to be discarded to allow single requests to take on a second
> form -- of becoming top-level elements.One
> argument I heard voiced was that the dsmlEnvelopeRequest has various optional
> attributes that are not relevant when there is a single request. 
> That's certainly true, but in that case those attributes need not be specified,
> right?I
> guess my position is that unless there's a concrete reason to the contrary,
> I'd like to see us agree on maintaining a single top-level element to simplify
> the client-server interaction.Thanks,-J