Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of julian.reschke@gmx.de
 designates 213.165.64.22 as permitted sender)
Message-ID: <4F917B97.4080907@gmx.de>
Date: Fri, 20 Apr 2012 17:07:03 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: oak-dev@jackrabbit.apache.org
CC: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
Subject: Re: oak-jcr: path handling
References: <4F8EDA46.1080403@gmx.de> <4F8F304A.4040402@apache.org>
 <4F902456.8080909@gmx.de> <4F903012.8070204@apache.org>
In-Reply-To: <4F903012.8070204@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

On 2012-04-19 17:32, Michael D�rig wrote:
> ... >> I do agree that in absence of local remappings, we can probably take
>> shortcuts in mapping, but do so, we still need to parse the paths (to
>> detect expanded names and identifier names).
>
> Yes, it does not save us from parsing. However it saves us from parsing
> and persisting (and having to look at) ugly long paths like
>
> /{http://www.jcp.org/jcr/1.0}system/{http://www.jcp.org/jcr/1.0}nodeTypes/{http://www.jcp.org/jcr/nt/1.0}folder/{http://www.jcp.org/jcr/1.0}childNodeDefinition/{http://www.jcp.org/jcr/1.0}primaryType
> ...

We'll need to parse them anyway. The question is where.

With respect to persistence: It would be possible to use expanded names 
in the interface, and let the MK implementation decide on how to persist.

For instance, one document management system I worked on in the past 
used namespace/name pairs as identifiers in it's API, but then 
internalized namespace names in a separate table, so that for the 
individual nodes just an integer key was needed.

I understand that we have decided to do things differently in the MK though.

> instead it would just be
>
> /jcr:system/jcr:nodeTypes/nt:folder/jcr:childNodeDefinition/jcr:primaryType

The format of the paths as transient things shouldn't matter a lot. The 
format of paths as persisted is an implementation detail. Right now we 
expose that detail in the MK API, and that's what I'm unhappy with. But 
I acknowledge it's apparently just me :-).

>> When you say:
>>
>> > The realisation of the map should live in oak-core. The effective
>> > remapping of names should be done in oak-jcr.
>>
>> I read that as:
>>
>> - oak-core will provide an API for handling namespace mappings
>
> Or maybe just a content model. But generally yes.

At some point we need to decide. If it just exposes the content then the 
mapping will reside entirely in oak-jcr.

>> - oak-core will accept MK paths and return MK paths
>
> Yes.
>
>>
>> - it's up to oak-jcr to map between MK paths and JCR paths
>
> Yes.
>
>>
>> If this is true then we will have to move the session namespace mappings
>> OAK's ContentSession, and the repository namespace registry impl into
>> OAK's ContentRepository, right?
>
> Ups... I don't get that ;-)
>
> However, if oak-jcr has access to above table (either through an API or
> through content) I think we are fine. In that case oak-jcr can:
>
> - implement registry wide namespace mapping
> - implement session local namespace mapping
> - register new namespace mappings
> - handle items with as yet unknown namespaces
> - cope with expanded forms and qualified forms
> ...

It appears the path of least resistance for now would be to

a) put all the mapping logic into oak-jcr, which includes

b) just assuming a certain place in the content tree for the mappings.

Once we have this working we can still decide what needs to be pushed down.

Makes sense?

Best regards, Julian