Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (asf.osuosl.org: domain of peeter.piegaze@gmail.com
 designates 64.233.182.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=ALhrznEwErz4kCqvx1ESR2xPP4qqmUKOzXhd7MSWQo+yX2VJ7EWtumlaiZ5GQkVO4EOPUPRYQ0tJjzULWF58lwy8QcM/agSsa42h9RzFKKlC+lqu8Z4AyQOkqEnYoR/zHVDvl9z6n/NJDHTS1Hu/xRhmdZpjqgy2W1rXILO4POw=
Message-ID: <3df33a250605040301u6acabf79v8d0255da85914a33@mail.gmail.com>
Date: Thu, 4 May 2006 12:01:13 +0200
From: "Peeter Piegaze" <peeter.piegaze@day.com>
Sender: peeter.piegaze@gmail.com
To: dev@jackrabbit.apache.org
Subject: Re: Conflicting propertyDefinitions within a nodeType
In-Reply-To: <90a8d1c00605040213r4925e01cifbf7b84f514cafdc@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: 
 <OF486A6CAF.198FAFB9-ON85257163.0077107A-85257163.00779D8A@us.ibm.com>
	 <90a8d1c00605040213r4925e01cifbf7b84f514cafdc@mail.gmail.com>

Hi David,

Actually, the proposed maintenance release (JCR 1.0.1) is publicly
available, so you can have a look at it:

http://jcp.org/aboutJava/communityprocess/maintenance/jsr170/index.html

The revised section that addresses your concerns is 6.7.8 (pp. 135-6).
There is a diff version included so you can see the changes from 1.0
highlighted.

I should point out that this is not a final release, so theoretically
it could change. But frankly that is pretty unlikely...unless, of
course, you yourself identify a problem :-)

Cheers, hope this helps,
Peeter

On 5/4/06, Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:
> On 5/3/06, David Kennedy <davek@us.ibm.com> wrote:
> > I have 2 nodeType definitions where one inherits from the other.  Both
> > have a definition for a property having the same name.  In this particu=
lar
> > case they happened to be the same (have the same attribute values).  On
> > registration of the nodeType, I get a NodeTypeConflictException:
> > "ambiguous property definition". Since the inheritance model of nodeTyp=
e
> > definition is left up to the implementation, what is jackrabbit's model=
?
> > Why wouldn't the subtype definition override the supertype's definition=
?
>
> the short answer is: in order to stay out of trouble ;-)


>
> as you mentioned the node type inheritance behavior is not clearly define=
d.
>
> let's take types T1 and T2.
>
> T1 has a non-mandatory string-valued property, P.
> T2 has a mandatory string-valued property, P.
>
> T2 could theoretically be a subclass of T1. T1 on the other hand
> cannot be a subclass of T2 because the 'mandatory' constraint
> of T2 would be violated.
>
> the issue of overriding property or child node definitions in
> node type subclasses is not just limited to the 'mandatory' flag.
>
> e.g. the 'protected' flag, required type, value constraints etc.
> pose similar problems.
>
> take for example a property definition with a value constraint
> being overridden in a subclass by a property definition with
> a different value constraint. if we would allow definitions to be
> overridden by more restrictive definitions in subclasses, how do
> we determine if a specific value constraint is more restrictive than
> another? this could be very difficult, especially in the case of
> regular expressions...
>
> another example: T1 defines a multi-valued property P. T2 extends
> from T1 and defines a single-valued but otherwise identical property.
> is T2's definition of P overriding T1's definition or is it just
> adding another definition? nt:unstructured for that matter contains
> two property definitions that are identical except for their 'multiple'
> flag.
>
> the current implementation in jackrabbit is absolutely compliant
> with the jsr-170 spec. i agree that node type inheritance behavior needs =
to be
> clarified; we've already discussed this issue earlier in the jsr-170
> expert group.
> the good news is that the next maintenance release (jcr 1.0.1) will
> address this
> issue.


>
> cheers
> stefan
>
> >
> > FWIW, this is where it is failing in EffectiveNodeType:
> >
> >                                 if (pd.getRequiredType() =3D=3D
> > epd.getRequiredType()
> >                                         && pd.isMultiple() =3D=3D
> > epd.isMultiple()) {
> >                                     // conflict
> >                                     String msg =3D "The property defini=
tion
> > for '"
> >                                             + name + "' in node type '"
> >                                             + def.getDeclaringNodeType(=
)
> >                                             + "' conflicts with node ty=
pe
> > '"
> >                                             +
> > existingDef.getDeclaringNodeType()
> >                                             + "': ambiguous property
> > definition";
> >
> > David
> >
>