Re: schema revisions

[Shon Vella <SVELLA@novell.com>]

I would prefer to only go half way on the attribute thing, something more like:

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

The rational being that it is possible to have values that are very large and attribute normalization rules re: whitespace etc. would require extra escaping on the value.

A couple of other considerations:

Should the desc attribute be called name to be consistent with the name attribute on dsml:attr from DSML 1.0?
Should there be an optional encoding attribute similar to the one on dsml:value in DSML 1.0 so that binary values can be represented?


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/08/01 06:09PM >>>
I've attached a revision of DSMLv2.xsd that uses attributes rather than
elements in the leaves of the filter grammar. Note that we're not
'inventing' a new syntax, but rather adapting the RFC2251 grammar to the XML
domain.

Jeff's example with these revisions is:

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

which is less verbose and just as usable with XML technologies such as XSLT
which is the basic consideration for making the filter be an XML object, as
I believe others have already discussed. Within the context of a DSMLv2
server there will be opportunities to perform transformations of filters,
predications on filters, etc. For example, a DSMLv2 agent/server might find
it useful to be able to add a condition to the <and> above for example, <is
desc="external"/>. With an XML representation it is straightforward to use
XPath to locate the conjunct and then using a DOM setter to add the test for
before further processing is performed or as the overall object is
reserialized for transport to another DSMLv2 agent/server.

ciao,
Christine

Jeff Parham wrote:

> 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