On 2012-04-18 23:21, Michael Dürig wrote:
Hi,
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.
Michael
...
Mostly.
There can be JCR prefix/namespace mappings that do not have a MK
counterpart yet (not saved).
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).
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).
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
- oak-core will accept MK paths and return MK paths
- it's up to oak-jcr to map between MK paths and JCR paths
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?
Best regards, Julian
