Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4F91F40D.7070902@apache.org>
Date: Sat, 21 Apr 2012 00:41:01 +0100
From: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
CC: oak-dev@jackrabbit.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>
 <4F917B97.4080907@gmx.de> <4F918114.5070305@apache.org>
 <4F91821E.1040807@gmx.de>
In-Reply-To: <4F91821E.1040807@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


On 20.4.12 16:34, Julian Reschke wrote:
> On 2012-04-20 17:30, Michael D�rig wrote:
>>>> 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?
>>
>> Yes. Only that I'm not sure whether oak-jcr is the right place. I think
>> there is no reason to make the mk prefixes visible outside oak-core.
>>
>> Michael
>> ...
>
> So move it all down into oak-core? That'll require that oak core handles
> session-scoped namespace mapping changes...

I committed a prove of concept implementation of a NameSpaceRegistry in 
r1328538. This implementation is in memory only but demonstrates how the 
mapping between qualified names, expanded names and microkernel names 
could be done. NameSpaceRegistry is in oak-core such that (1) oak-core 
clients can discover jcr namespaces and their current prefixes and (2) 
that oak-core can use it internally to find the microkernel names from 
given jcr names.

For session scoped mappings, oak-jcr should conceptually use its own set 
of mappings and pass this down to oak-core whenever necessary (i.e. on 
commit).

Michael

>
> Best regards, Julian