On 2012-05-10 11:00, Michael Dürig wrote:
On 10.5.12 9:43, Julian Reschke wrote:
On 2012-05-10 10:29, Michael Dürig wrote:
2) we didn't round-trip a relative path of ".". Now we do, but I'm
not
sure I got the mapping correct. What is a same-node reference in Oak
path syntax? "." or empty string?
well, i would expect "."
Indeed.
Currently there is no notion for .. and . in Oak paths and I would leave
it at that. I.e. oak-jcr needs to take care to normalize paths before it
passes them to the Oak API. But of course we should use the
JcrPathParser to do that.
So how do you express a reference to the parent node in a path property
inside Oak Core?
My thinking was to make this opaque to oak-core. That is, set the value
of the path property to the jcr path and let oak-jcr handle it. Unless
there is a case (which might well be) where we need to dereference such
paths properties from within oak-core this should work.
I don't think that's going to work as then the persisted path depends on
session namespace mappings.
I also fear that we need to be able to
round-trip relative paths like "../foo/bar" in path values, which we
currently do not. Do we need a "normalize" flag???
i would expect that we need it sooner or later.
+1
The JcrPathParser does already normalise. What it can't do is
normalising "negative" paths like ../foo or foo/../..
Yup. What I meant is that we may need a way to switch off normalizing.
Ah ok. That shouldn't be difficult.
See my other mail how that could be handled with the current setup.
Alternatively we could also have the JcrPathParser accept a prefix path
against which normalisation is done.
This might break assumptions on stability of path property values. If
the client sets a relative path it probably expects it to stay relative,
so that the path continues to work when the node is moved.
I was just talking of resolving it (under the above opaqueness
assumption). I didn't mean to save that dereferenced and normalized path
to the path property. That surely doesn't work.
OK, trying to summarize:
- we allow relative paths inside path values; but we need to oakify them
with respect to prefixes
- open question: we allow relative paths such as ".." but does that
imply we do not normalize at all?
- relative paths in other methods (such as getNode()) are resolved to an
absolute Oak path in oak-jcr
I think this means we need a variant of getOakPath() that doesn't make
the path absolute. Any preferences about whether this should be a flag
or a new method?
Best regards, Julian
