[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: schema revisions
I think the issue has more to do with the server than the client. For the client constructing either format is more or less the same. But for the server the issues are: 1) If your server is a server that speaks DSML, but is not a LDAP server, why should you have to know how to parse both XML and LDAP filters? This is exactly the case for Access360 enRole agents which use DSML as the protocol (via our DAML spec). 2) If your server is a gateway to an LDAP server, then there could very well be some cases where the filter might need to be transformed before forwarding to the LDAP server. In this case it seems logical to transform the filter using XSLT and then walking the resulting filter, reconstructing the new LDAP filter. In both case you could certainly pass the filter as a simple string and parse it on the server, but why? An LDAP filter is by it's very nature a recursive list of assertions. It is very well suited to representing in XML. Let me pose the opposite question: What is the advantage of using a single string? Jeff Bohren Access360 -----Original Message----- From: Jeff Parham [mailto:jeffparh@windows.microsoft.com] Sent: Wednesday, August 08, 2001 3:43 PM To: Christine Tomlinson Cc: dsml@lists.oasis-open.org Subject: RE: schema revisions Re #1, your equivalent of <filter>(&(objectClass=person)(|(sn=smith)(title=developer)))</filter> would be <filter> <and> <eql> <desc>objectClass</desc> <val>person</val> </eql> <or> <eql> <desc>sn</desc> <val>smith</val> </eql> <eql> <desc>title</desc> <val>developer</val> </eql> </or> </and> </filter> Is that correct? Can someone crystallize the advantages of using an XML transformation of the raw RFC 2251 filter structure over use of the RFC 2254 string representation? Someone mentioned the desire to transform the filter using XSL, but offhand I can't think of an example where a client would need to do this. Do you envision DSML clients building these filters element-by-element? Thanks, -J -----Original Message----- From: Christine Tomlinson [mailto:chris.tomlinson@sun.com] Sent: Tuesday, August 07, 2001 6:10 PM To: DSML version 2 Subject: schema revisions The attached is a revision of the DSMLv2.xsd and Batch.xsd with the following items: 1) completes the Filter definition 2) incorporates Jeff's changes for: Adds controls to the LDAPResult element, Removes the dn attribute from ExtendedResponse, requestID is an attribute and added to envelopes in Batch.xsd, oc-value minOccurs='0', I didn't see where the typo in LDAPErrorCode enumeration was? 3) bindRequest and bindResponse are added. Intent is that bindRequest MAY be supported and if supported "simple" BindMechanism MUST be supported and the others (cram-MD5, digest-MD5, and kerberos) MAY be supported. Further, an implementation of bindRequest will perform ALL necessary exchanges prior to returning the bindResponse. There is NO need for sequencing at the DSML level. ciao, Christine
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC