jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: oak-jcr: path handling
Date Wed, 18 Apr 2012 17:52:12 GMT
hi julian

> 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 think 3) has to flavors:

3.1) namespace registry: repository level mapping of prefix to
      namespace uri that can be modified using the jcr NamespaceRegistry
3.2) session level namespace remapping

the first shouldn't be too problematic for the TCK as we can use
a hardcoded list until we have the proper implementation ready.

however, the second one has an impact on how we deal with jcr
names all over the place. currently we just pass them to oak-api
instead of having some sort of 'resolve-to-internal-representation'
whatever that might be in the end.

and this 'resolve-to-internal-representation' does not only affect
the local namespace remapping but also effects the name and
path handling you listed in 1) and 2).

> 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.
> 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?

IMO that was the responsibility of oak-jcr using information
obtained from oak-core to populate the namespace registry and
possibly identifier-resolution. something like:

- a namespace mapping that allows to convert names passed to the
   jcr API to the internal representation
   . local namespace remapping (prefix -> internal)
   . lookup uri to internal

- a name/path conversion that uses the namespace mapping to
   . jcr-name/path to internal representation
   . qualified name/path to internal representation
   . identifier path to internal representation

for the last (identifier path) we should define what's the nature
of Node.getIdentifier().

> Also, I'd like to point out that spi-commons already has necessary
> concepts for this; do we *really* want to reinvent that?

my preference was "no" :)
but maybe we have to rewrite it using whatever looks useful?
the basic concepts are IMO the same but the implementation
differs due to the move that internal representation isn't
the qualified name representation any more.

kind regards

> Best regards, Julian

> (*) I'm still unhappy about that, for the record.

View raw message