RE: Draft DSML 2.0 Requirements

[James Tauber <JTauber@bowstreet.com>]

> It's great to see you guys get this requirement document together.  I'm
still having 
> problem sending my responses to the dsml list (I do not have problem 
> receiving it), so I thought I could send to the active participants ( let
me know if 
> I miss others ). 

I hope you don't mind but I've CCed the list on this.

> Could you please clarify the requirements 4 and 6. They seem contradict. 
> 4) Operations in DSML 2.0 shall be described in terms of an abstract API
which is 
> mapped to SOAP calls 
> 6) DSML 2.0 shall provide for all the operations in LDAP version 3. 

Here is how I envisage the DSML 2.0 spec:

1. a data model that closely resembles and LDAPv3 directory (but is just
generic enough to also allow the RDF data model as it is so close to LDAP)

2. a mapping from that data model to the specifics of LDAPv3 (I don't know
how necessary this part will be)

3. an abstract API for manipulating the data model. The API should allow for
all LDAPv3 operations (semantically).

4. a mapping of the abstract API to a series of SOAP calls.

> re we saying that every DSML 2.0 operation will have the corresponding
SOAP API ?  

I'm imagining that every DSML 2.0 operation will be a SOAP call.

> For example, SOAP Update(...), Create(...), etc ? If this is the case, the
user 
> could either send a DSML document or send SOAP envelopes for achieving the
same 
> results. 

I'm imagining it will always be a SOAP call. DSML will describe the methods
and the payload format.

> What I envision is a little bit different. I propose that the DSML 2.0
operations 
> (modify,add,delete,etc) should be described in DSML document only, and
make SOAP as 
> one of ways to transport the document. The document, itself, could also be
read 
> directly by the directory services. Directory Services could also accept a
simple 
> HTTP POST + DSMLv2.0 request, in addition to SOAP calls. 

If we get the abstract API right, we should be able to specify multiple
mappings along the lines you propose. If possible, I would like to delay the
decision of whether to do one, the other, or both and I think the approach
of developing an abstract API will enable us to do this.

> So, the XML document may look like this: 
> <update  dn="CN=John Smith,OU=Marketing,O=Example, C=US"> 
>      <sn>Johnson</sn> 
>      <telephoneNumber>425 902 5211</telephoneNumber> 
> </operation>
>
> and the pseudo SOAP method signature would look like this: 
>      
>   SendUpdategrams( [in] string dsmlDoc, [out] string dsmlStatus ); 
> we'll stream the DSML Doc into the dsmlDoc parameter, and get the status
of the 
> operations in the dsmlStatus parameter.  
>
> Comments ? 

I like this but don't think we should commit to it at this stage. Perhaps we
should make it a requirement of the abstract API that it be able to support
both a direct mapping to XML as well as with a SOAP envelope.

James