On 22.4.12 13:20, Julian Reschke wrote:
On 2012-04-21 01:41, Michael Dürig wrote:
...
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
> ...
Right now it does just prefix/prefix/ns (re-)mapping, right?
Yes
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.
Ack. As you write in the TODO, it will then need to be exposed on
ContentSession, so that oak-jcr can use it.
Yes. I didn't think of this too much but ContentSession is probably the
right place.
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).
So we would have remapping taking place both in oak-jcr and oak-core? I
also do not understand what's special about commit() here; the session
remappings are also needed for all read methods, such as getProperty and
getNode().
oak-jcr will have to take care of session scoped re-mappings. Scrap my
remark re. commit, I got that wrong.
It appears we have a clear understanding of what a JCR path is (as
specified in JCR 2.0), of what a MK path is, but not what kind of paths
we pass down from oak-jcr to oak-core...
I commited org.apache.jackrabbit.oak.namepath.Paths in the same revision
to start clarifying this. See the class comment. My idea is, to use JCR
paths where each element is a qualified name without an index. The
prefix is then interpreted wrt. the registered namespaces.
Michael
Best regards, Julian
