Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of chadmichaeldavis@gmail.com
 designates 209.85.214.42 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=eOA5hkHyJcw/c87xxGFJw3zv6jAdG18vJbZEKk8dxLidMbAFJ+kw1LI6OcAxseHxIc
         Q0HTeIqk7tHFwohnH7nO/Ibs1qW+mbM/ylnreSwBhB+ej0NzSqCjR99rCm1FTtwkgUlk
         O9O0mtaojbtDZVXY4aN4i1NHGUQFg/6rCTEKA=
MIME-Version: 1.0
In-Reply-To: <AANLkTin-qKucQ6hTtnNaXqySADJHwkUoe02fFwzbH5bT@mail.gmail.com>
References: <AANLkTin-qKucQ6hTtnNaXqySADJHwkUoe02fFwzbH5bT@mail.gmail.com>
Date: Sat, 26 Feb 2011 14:29:23 -0700
Message-ID: <AANLkTik-0TLQnOxX76XFo3kfKW5Q+aZTCnhhFffmNn0W@mail.gmail.com>
Subject: Re: same name sibling issuesq
From: ChadDavis <chadmichaeldavis@gmail.com>
To: users@jackrabbit.apache.org
Content-Type: multipart/alternative; boundary=001485f77378f45039049d3623bb

--001485f77378f45039049d3623bb
Content-Type: text/plain; charset=ISO-8859-1

> Here's my node types:
>
> // The namespace declaration
> <me = 'http://me.com'>
>
> //my node types
> [me:document] > nt:hierarchyNode, nt:unstructured, mix:versionable,
> mix:lockable
>   - me:docType (STRING)
>
> [me:folder] > nt:folder, nt:unstructured, mix:referenceable, mix:lockable
>
>
> Oddly enough, when I try to move a node ( me:folder ) to a location that
> would cause a same name sibling conflict, it almost always rejects me with
> an ItemExistsException.  However, a couple of times we've been able to
> witness behavour where the session.move allows the same name sibling to be
> created.  Interestingly, we do a parallel move on a second workspace
> directly after this and that second workspace move tossed the
> ItemExistsException even when the first one didn't.  Note, all of the
> "parent" nodes in these moves are me:folder types.
>
> When I started to review this issue, I noticed that nt:unstructured allows
> SNS, and my node types all extend nt:unstructured.  To me not yet fully
> matured understanding of defining node types, this leads me to believe that
> my node types SHOULD allow SNS.
>
> So, two questions persist:
>
> 1) Do these node type definitions allow for SNS?  ( SNS of type me:document
> or me:folder, and all under a parent of me:folder )
>


> 2) Does my me:folder definition allow for SNS of me:document and me:folder?
>
>
According to my reading of the specification, with regards to node type
inheritance, I come up with the following effective node type definition for
me:folder  (note: I'm omitting mixin related properties and properties in
general as I'm only concerned with child node aspects here )

[me:folder] > nt:folder, nt:unstructured, mix:referenceable, mix:lockable

 + * (nt:hierarchyNode) VERSION                                   //from
nt:folder
 + * (nt:base) = nt:unstructured sns VERSION               // from
nt:unstructured

So, if I'm creating a me:folder under an me:folder, which child node rule
applies.  The spec simply says that they are both "additive", because of
being "residual".  My guess would be that the first rule applies, since my
me:folder type is, from a type perspective, more specifically an instance of
nt:hierarchyNode than an instance of nt:base.  But I am, admittedly, a bit
lost here.

--001485f77378f45039049d3623bb--