jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: oak-jcr: path handling
Date Fri, 20 Apr 2012 23:41:01 GMT

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 


> Best regards, Julian

View raw message