Allowed top-level elements

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

Title: Message

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