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 Wed, 18 Apr 2012 21:21:14 GMT


On 18.4.12 16:14, Julian Reschke wrote:
> Hi there,
> to get more of the TCK passing, we really need to get the path handling
> done.
> Reminder, this involves:
> 1) handling expanded names,
> 2) handling identifier pathsa, and
> 3) mapping (and occasionally creating) namespace prefixes.

I created OAK-61 for this last week.

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


> Also, I'd like to point out that spi-commons already has necessary
> concepts for this; do we *really* want to reinvent that?
> Best regards, Julian
> (*) I'm still unhappy about that, for the record.

View raw message