Re: Allowed top-level elements

[Shon Vella <SVELLA@novell.com>]

I agree that it makes sense to allow either the enveloped or the naked form in the general specification and leave it up to a specific binding as to which it will use, but I think an individual binding would be more straightforward and less confusing if it picked one or the other.

Shon Vella
Software Engineer, Consultant
svella@novell.com
Novell, Inc., the leading provider of Net services software
www.novell.com 

>>> Christine Tomlinson <chris.tomlinson@sun.com> 08/23/01 07:44PM >>>
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