RE: schema revisions

[Jeff Bohren <JBohren@access360.com>]

1) Simplifying servers should be a consideration. It certainly is to
Access360, since all our agent are "servers". Also, it's a lot harder to
write a generic filter parser than it is to write a small bit of code to
write out a specific filter.

2) Doing the filter in XML is really not any harder for the client.
Writing the code to express:

<filter> 
  <and> 
    <eql desc="objectClass" value="person"/> 
    <or> 
      <eql desc="sn" value="smith"/> 
      <eql desc="title" value="developer"/> 
    </or> 
  </and> 
</filter> 

Is really no more difficult than (formated to be equivalent):

<filter>
  (
    (objectClass=person)
    (|
      (sn=smith)
      (title=developer)
    )
   )
</filter>

Actually, they are fairly equivalent when you think about, except the
first way has other advantages.

3) Being compact is not an issue. As you can see from my example,
ignoring white space, they are only a few characters per filter
different. If that difference is a problem, then XML should not be used
at all.

4) Well defined and well tested are not issues either. As Christine
noted, we are just adapting a well-defined, well-tested standard to
being represented in XML.

Jeff B.


-----Original Message-----
From: Jeff Parham [mailto:jeffparh@windows.microsoft.com]
Sent: Wednesday, August 08, 2001 4:47 PM
To: Jeff Bohren; Christine Tomlinson
Cc: dsml@lists.oasis-open.org
Subject: RE: schema revisions


Simplification of the servers is not really an objective in my mind.
Simplifying the *clients* on the other hand allows us to extend the
reach of the directory to less and less sophisticated clients (and
client developers), which is the overarching goal of DSML 2.

The advantages of RFC 2254 are easier for me to see -- it's a compact,
well-defined, well-tested representation of search filters that we don't
have to invent ourselves.  Maybe there are sufficient reasons to scrap
that from the client perspective and instead use an XML representation,
but that's not abundantly obvious to me at this point.

-J

-----Original Message-----
From: Jeff Bohren [mailto:JBohren@access360.com] 
Sent: Wednesday, August 08, 2001 1:14 PM
To: Jeff Parham; Christine Tomlinson
Cc: dsml@lists.oasis-open.org
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


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: dsml-request@lists.oasis-open.org