Re: schema revisions

[Christine Tomlinson <chris.tomlinson@sun.com>]

I agree with your considerations for attributes versus content on 'value'. I'd meant to do that consistently and will repair the DSMLv2.xsd for the next revision.

I'm not opposed to using 'name' rather than 'desc' and will make that change as well unless there's an objection.

ciao,
Christine

Shon Vella wrote:

> 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