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 Thu, 19 Apr 2012 15:32:34 GMT


On 19.4.12 15:42, Julian Reschke wrote:
> On 2012-04-18 23:21, Michael Dürig wrote:
>>> We have decided early on that the MK persists prefixes, not namespace
>>> names, plus mapping information (*). It may seem like this makes things
>>> easier, but it does not; the namespace mapping used by the JCR client
>>> may be different from the one in the MK, so remapping needs to happen in
>>> any case.
>>
>> Its not about making it easier, its about specialising for the most
>> common case which is that there are only a few re-mappings if any at all.
>>
>>>
>>> Let's use "jcr path" and "mk path" (and * name) as terminology here.
>>>
>>> Where does this mapping need to happen? oak-jcr or oak-core?
>>
>> The realisation of the map should live in oak-core. The effective
>> remapping of names should be done in oak-jcr.
>>
>> Implementation wise that map can be represented by a table with three
>> rows: prefix of the mk name (let's call that mk prefix), namespace and
>> jcr prefix. Since JCR namespace mapping is bijective, we can do all
>> necessary resolutions: from expanded form to qualified form and back and
>> also from mk name to jcr name and back. Furthermore it also covers all
>> the necessary remapping operations. Finally, if we adhere to the
>> convention that the mk prefix is the same as the jcr prefix at the time
>> the respective namespace was first used, we get a representation of mk
>> paths which largely coincides with the one of jcr paths.
>>
>> Michael
>> ...
>
> Mostly.
>
> There can be JCR prefix/namespace mappings that do not have a MK
> counterpart yet (not saved).

Yes. The session where this is happening would have to keep that 
additional entries in a local copy of said table.

>
> There could be namespaces persisted in the MK that aren't in the
> registry yet (because in theory, the number of namespaces could be huge,
> and there's no point in exposing them all until they are needed).

According to JSR283, such namespaces get a jcr prefix (auto) assigned 
the first time such an item is read. With the approach from above this 
means, that a mk prefix is auto assigned (i.e. an entry in said table 
would be added) the first time an item in a yet unregistered namespace 
is written.

>
> 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

instead it would just be

/jcr:system/jcr:nodeTypes/nt:folder/jcr:childNodeDefinition/jcr:primaryType


>
> 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.

>
> - 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

Michael


>
>
> Best regards, Julian

Mime
View raw message