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
Best regards, Julian
