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
commit).
Michael
Best regards, Julian
