On 2012-04-19 17:32, Michael Dürig wrote:
... >> 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).
Yes, it does not save us from parsing. However it saves us from parsing
and persisting (and having to look at) ugly long paths like
/{http://www.jcp.org/jcr/1.0}system/{http://www.jcp.org/jcr/1.0}nodeTypes/{http://www.jcp.org/jcr/nt/1.0}folder/{http://www.jcp.org/jcr/1.0}childNodeDefinition/{http://www.jcp.org/jcr/1.0}primaryType
...
We'll need to parse them anyway. The question is where.
With respect to persistence: It would be possible to use expanded names
in the interface, and let the MK implementation decide on how to persist.
For instance, one document management system I worked on in the past
used namespace/name pairs as identifiers in it's API, but then
internalized namespace names in a separate table, so that for the
individual nodes just an integer key was needed.
I understand that we have decided to do things differently in the MK though.
instead it would just be
/jcr:system/jcr:nodeTypes/nt:folder/jcr:childNodeDefinition/jcr:primaryType
The format of the paths as transient things shouldn't matter a lot. The
format of paths as persisted is an implementation detail. Right now we
expose that detail in the MK API, and that's what I'm unhappy with. But
I acknowledge it's apparently just me :-).
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
Or maybe just a content model. But generally yes.
At some point we need to decide. If it just exposes the content then the
mapping will reside entirely in oak-jcr.
- oak-core will accept MK paths and return MK paths
Yes.
- it's up to oak-jcr to map between MK paths and JCR paths
Yes.
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?
Ups... I don't get that ;-)
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?
Best regards, Julian
