Re: Allowed top-level elements

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

Jeff Parham wrote:

> How about the following:
>
> (1) A DSMLv2-compliant transport MUST accept dsmlEnvelopeRequests OR
> individual requests as top-level elements.

+1

>
>
> (2) A DSMLv2-compliant transport MUST NOT accept both
> dsmlEnvelopeRequests AND individual requests as top-level elements.

-1 What's the rationale for prohibiting this behavior? It doesn't hurt a
client. We can use 'must_understand' with the SOAP binding to clarify.

>
>
> (3) Since the transports that the working group is defining -- namely
> the file (LDIF replacement) transport and the SOAP transport -- require
> dsmlEnvelopeRequest, the flow and focus of the overall spec should
> continue to be on interactions that utilize the dsmlEnvelopeRequest
> element.  Leaving the details of interactions that do not utilize the
> dsmlEnvelopeRequest element to future transport specifications will
> allow for maximum flexibility in these yet-to-be-defined transports
> while letting the working group concentrate on refining and giving
> examples for the already-defined transports.
>
> -J
>
> -----Original Message-----
> From: Shon Vella [mailto:SVELLA@novell.com]
> Sent: Friday, August 24, 2001 6:15 AM
> To: chris.tomlinson@sun.com; Jeff Parham
> Cc: dsml@lists.oasis-open.org
> Subject: Re: Allowed top-level elements
>
> 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
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>