RE: Allowed top-level elements

[Jeff Parham <jeffparh@windows.microsoft.com>]

How about the following:

(1) A DSMLv2-compliant transport MUST accept dsmlEnvelopeRequests OR
individual requests as top-level elements.

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

(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