Both of the following are valid:
{ specificationFilter or: { item:student, item:faculty } }
{ specificationFilter (&(objectClass=person)(title=engineer)) }
Makes sense?
On 9/20/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:
>
> Can you describe how it is backwards compatible? Sounds to me like the
> syntax is not compatible.
>
> Alex
>
> On 9/20/07, Ersin Er < [EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I considered this before and concluded with the most appropriate
> > solution IMO. Current solution is completely backward compatible. The syntax
> > supports both refinements and filters for the specificationFilter component
> > of the subtreeSpecification.
> >
> > I can try to explain more why I did not choose other alternative if you
> > wish.
> >
> >
> > On 9/20/07, Alex Karasulu < [EMAIL PROTECTED]> wrote:
> > >
> > > Ersin,
> > >
> > > I got an interesting idea while thinking about subtrees and
> > > specifications. As you know we complied
> > > up until recently strictly with the X.500 administrative model with
> > > respect to subtreeSpecifications. The
> > > changes we added to handle refinements which were filters broke away
> > > from X.500 in many ways.
> > >
> > > I was just thinking that it may be possible to use an
> > > extendedSubtreeSpecification attribute which
> > > extends a subtreeSpecification. However the only problem with this is
> > > the fact that the attributeType
> > > subtyping another cannot switch the SYNTAX of the AT. This is what I
> > > always thought but perhaps
> > > I am wrong (I hope) but if I am wrong I think we can leverage AT
> > > extension while remaining compliant.
> > >
> > > Basically we can allow our subentry objectClasses to include
> > > extendedSubtreeSpecifications instead
> > > of just the usual subtreeSpecification.
> > >
> > > WDYT?
> > >
> > > Alex
> > >
> > >
> >
> >
> > --
> > Ersin Er
> > http://www.ersin-er.name
>
>
>
--
Ersin Er
http://www.ersin-er.name
