Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 80024 invoked from network); 20 Sep 2007 05:58:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 20 Sep 2007 05:58:19 -0000 Received: (qmail 36508 invoked by uid 500); 20 Sep 2007 05:58:10 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 36461 invoked by uid 500); 20 Sep 2007 05:58:10 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 36450 invoked by uid 99); 20 Sep 2007 05:58:10 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Sep 2007 22:58:10 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ersin.er@gmail.com designates 209.85.198.184 as permitted sender) Received: from [209.85.198.184] (HELO rv-out-0910.google.com) (209.85.198.184) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Sep 2007 06:00:07 +0000 Received: by rv-out-0910.google.com with SMTP id g11so338034rvb for ; Wed, 19 Sep 2007 22:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=9vHls+F0fbMOuUv5OSjj5PQ2OdQYvg+UBcVAvtZsqlY=; b=UdFnOWNo83DMi238gDzQVkUNKkMGWK1+LF1WuBhafq9vqK9vTh0RI3A7GIOXvAkOjzzGMQgNYxb4HpJQT9cXOu3Qsbg8QP+T33RcaYyLooMvjYRw0TS55lVlMY/iOlpqZsWFulzMTmAVVyW47p7u+2eVSYQn/FCfs/PiiawAUlM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=pc6HSoeb3t/RZy3N2IiZJsq+glZI869xaKToW7KuI5NIcYbfhRpVukVwvLmb1I18++ktlo9j1tl1f3qCoFgDcFngYn08fLc2KtrLXleeN2P81dpxpQyQzD+rQbkguLrE8jE7m1Wxxbjcd7s3tw01KdM22e8vggYfKe7PgAbeDDo= Received: by 10.141.122.20 with SMTP id z20mr392090rvm.1190267863118; Wed, 19 Sep 2007 22:57:43 -0700 (PDT) Received: by 10.141.136.9 with HTTP; Wed, 19 Sep 2007 22:57:43 -0700 (PDT) Message-ID: Date: Thu, 20 Sep 2007 08:57:43 +0300 From: "Ersin Er" To: "Apache Directory Developers List" Subject: Re: [ApacheDS] extendedSubtreeSpecification In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9344_25039071.1190267863124" References: X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_9344_25039071.1190267863124 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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 < ersin.er@gmail.com> 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 < akarasulu@apache.org> 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 ------=_Part_9344_25039071.1190267863124 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 <akarasulu@apache.org> 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 < ersin.er@gmail.com> 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 < akarasulu@apache.org> 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 ------=_Part_9344_25039071.1190267863124--