You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ak...@apache.org> on 2007/09/20 07:19:29 UTC
[ApacheDS] extendedSubtreeSpecification
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
Re: [ApacheDS] extendedSubtreeSpecification
Posted by Alex Karasulu <ak...@apache.org>.
Yes yes but this is not valid syntax for a subtreeSpecification according to
X.500. It's not a "syntax refinement" (not subtreeRefinement). Basically
our interpretation will make tools dealing with SSs sh*t themselves.
Alex
On 9/20/07, Ersin Er <er...@gmail.com> wrote:
>
> 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 <ak...@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
>
Re: [ApacheDS] extendedSubtreeSpecification
Posted by Ersin Er <er...@gmail.com>.
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 <ak...@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
Re: [ApacheDS] extendedSubtreeSpecification
Posted by Alex Karasulu <ak...@apache.org>.
Can you describe how it is backwards compatible? Sounds to me like the
syntax is not compatible.
Alex
On 9/20/07, Ersin Er <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
Re: [ApacheDS] extendedSubtreeSpecification
Posted by Alex Karasulu <ak...@apache.org>.
Yep that's what I've been trying to say:
"Ok we need to talk to Steven Legg who's working on those admin model
drafts currently about this. It's very important that we align with the
new
specifications which will emerge."
On 9/20/07, Ersin Er <er...@gmail.com> wrote:
>
> I perfectly understand the problem here and I tried to choose the best
> solution at the time of implementing this with relevant conditions. So,
> let's develop a new plan and consult to the guys at IEFT.
>
> On 9/20/07, Alex Karasulu <ak...@apache.org> wrote:
> >
> > OK you're not getting what I am trying to say. If you take the X.500constructs based on
> > ASN.1 and overlay them onto the LDAP plane using the traditional means
> > to map them over with EBNF then you're going to have a problem. Steven is
> > trying to doing this now and when he does that he's going to constrain
> > filters if that's the representation he chooses to use, to only allow
> > objectClass attributes.
> >
> > If he uses a constrained filter (only with objectClass attributes)
> > instead of some alternate representation for refinement expressions, then
> > we're good. If he does not then we have a problem.
> >
> > Does this explanation make more sense?
> >
> > Alex
> >
> >
> > On 9/20/07, Ersin Er < ersin.er@gmail.com> wrote:
> > >
> > > This is an LDAP extension. It cannot be expressed in terms of X.500constructs. Current grammar cannot be expressed with
> > > ASN.1 because it breaks the ASN.1-to-String encoding schemes. I had
> > > also discussed this on the page I have pasted on this thread I think.
> > >
> > > On 9/20/07, Alex Karasulu < akarasulu@apache.org> wrote:
> > > >
> > > > Ok we need to talk to Steven Legg who's working on those admin model
> > > > drafts currently
> > > > about this. It's very important that we align with the new
> > > > specifications which will emerge.
> > > >
> > > > Alex
> > > >
> > > > On 9/20/07, Ersin Er <er...@gmail.com> wrote:
> > > > >
> > > > > BTW, here is my discussion on the topic I wrote down before:
> > > > >
> > > > > http://cwiki.apache.org/confluence/display/DIRxSRVx11/Administrative+Model+Extensions
> > > > >
> > > > >
> > > > > 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
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Ersin Er
> > > http://www.ersin-er.name
> > >
> >
> >
>
>
> --
> Ersin Er
> http://www.ersin-er.name
>
Re: [ApacheDS] extendedSubtreeSpecification
Posted by Ersin Er <er...@gmail.com>.
I perfectly understand the problem here and I tried to choose the best
solution at the time of implementing this with relevant conditions. So,
let's develop a new plan and consult to the guys at IEFT.
On 9/20/07, Alex Karasulu <ak...@apache.org> wrote:
>
> OK you're not getting what I am trying to say. If you take the X.500constructs based on
> ASN.1 and overlay them onto the LDAP plane using the traditional means to
> map them over with EBNF then you're going to have a problem. Steven is
> trying to doing this now and when he does that he's going to constrain
> filters if that's the representation he chooses to use, to only allow
> objectClass attributes.
>
> If he uses a constrained filter (only with objectClass attributes) instead
> of some alternate representation for refinement expressions, then we're
> good. If he does not then we have a problem.
>
> Does this explanation make more sense?
>
> Alex
>
>
> On 9/20/07, Ersin Er < ersin.er@gmail.com> wrote:
> >
> > This is an LDAP extension. It cannot be expressed in terms of X.500constructs. Current grammar cannot be expressed with
> > ASN.1 because it breaks the ASN.1-to-String encoding schemes. I had also
> > discussed this on the page I have pasted on this thread I think.
> >
> > On 9/20/07, Alex Karasulu < akarasulu@apache.org> wrote:
> > >
> > > Ok we need to talk to Steven Legg who's working on those admin model
> > > drafts currently
> > > about this. It's very important that we align with the new
> > > specifications which will emerge.
> > >
> > > Alex
> > >
> > > On 9/20/07, Ersin Er <er...@gmail.com> wrote:
> > > >
> > > > BTW, here is my discussion on the topic I wrote down before:
> > > >
> > > > http://cwiki.apache.org/confluence/display/DIRxSRVx11/Administrative+Model+Extensions
> > > >
> > > >
> > > > 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
> > > >
> > >
> > >
> >
> >
> > --
> > Ersin Er
> > http://www.ersin-er.name
> >
>
>
--
Ersin Er
http://www.ersin-er.name
Re: [ApacheDS] extendedSubtreeSpecification
Posted by Alex Karasulu <ak...@apache.org>.
OK you're not getting what I am trying to say. If you take the
X.500constructs based on
ASN.1 and overlay them onto the LDAP plane using the traditional means to
map them over with EBNF then you're going to have a problem. Steven is
trying to doing this now and when he does that he's going to constrain
filters if that's the representation he chooses to use, to only allow
objectClass attributes.
If he uses a constrained filter (only with objectClass attributes) instead
of some alternate representation for refinement expressions, then we're
good. If he does not then we have a problem.
Does this explanation make more sense?
Alex
On 9/20/07, Ersin Er <er...@gmail.com> wrote:
>
> This is an LDAP extension. It cannot be expressed in terms of X.500constructs. Current grammar cannot be expressed with
> ASN.1 because it breaks the ASN.1-to-String encoding schemes. I had also
> discussed this on the page I have pasted on this thread I think.
>
> On 9/20/07, Alex Karasulu <ak...@apache.org> wrote:
> >
> > Ok we need to talk to Steven Legg who's working on those admin model
> > drafts currently
> > about this. It's very important that we align with the new
> > specifications which will emerge.
> >
> > Alex
> >
> > On 9/20/07, Ersin Er <er...@gmail.com> wrote:
> > >
> > > BTW, here is my discussion on the topic I wrote down before:
> > >
> > > http://cwiki.apache.org/confluence/display/DIRxSRVx11/Administrative+Model+Extensions
> > >
> > >
> > > 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
> > >
> >
> >
>
>
> --
> Ersin Er
> http://www.ersin-er.name
>
Re: [ApacheDS] extendedSubtreeSpecification
Posted by Ersin Er <er...@gmail.com>.
This is an LDAP extension. It cannot be expressed in terms of
X.500constructs. Current grammar cannot be expressed with
ASN.1 because it breaks the ASN.1-to-String encoding schemes. I had also
discussed this on the page I have pasted on this thread I think.
On 9/20/07, Alex Karasulu <ak...@apache.org> wrote:
>
> Ok we need to talk to Steven Legg who's working on those admin model
> drafts currently
> about this. It's very important that we align with the new specifications
> which will emerge.
>
> Alex
>
> On 9/20/07, Ersin Er <er...@gmail.com> wrote:
> >
> > BTW, here is my discussion on the topic I wrote down before:
> >
> > http://cwiki.apache.org/confluence/display/DIRxSRVx11/Administrative+Model+Extensions
> >
> >
> > 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
> >
>
>
--
Ersin Er
http://www.ersin-er.name
Re: [ApacheDS] extendedSubtreeSpecification
Posted by Alex Karasulu <ak...@apache.org>.
Ok we need to talk to Steven Legg who's working on those admin model drafts
currently
about this. It's very important that we align with the new specifications
which will emerge.
Alex
On 9/20/07, Ersin Er <er...@gmail.com> wrote:
>
> BTW, here is my discussion on the topic I wrote down before:
>
> http://cwiki.apache.org/confluence/display/DIRxSRVx11/Administrative+Model+Extensions
>
>
> On 9/20/07, Ersin Er <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
>
Re: [ApacheDS] extendedSubtreeSpecification
Posted by Ersin Er <er...@gmail.com>.
BTW, here is my discussion on the topic I wrote down before:
http://cwiki.apache.org/confluence/display/DIRxSRVx11/Administrative+Model+Extensions
On 9/20/07, Ersin Er <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
Re: [ApacheDS] extendedSubtreeSpecification
Posted by Ersin Er <er...@gmail.com>.
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 <ak...@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