Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4FAB839B.7060802@apache.org>
Date: Thu, 10 May 2012 10:00:11 +0100
From: =?UTF-8?B?TWljaGFlbCBEw7xyaWc=?= <mduerig@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: value conversions, and relative paths in Oak
References: <20120509155236.0F1F223889E1@eris.apache.org>
 <4FAA94B2.5010305@gmx.de> <4FAB6459.1030204@adobe.com>
 <4FAB7449.10000@gmx.de> <4FAB7C70.8070101@apache.org>
 <4FAB7FC6.3010806@gmx.de>
In-Reply-To: <4FAB7FC6.3010806@gmx.de>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit


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

Michael

>
>>>>> 3) Node.getNode(".") failed because it looked for a child called
>>>>> ".". If
>>>>> have added a hack to make this work, but I'm wondering how to do this
>>>>> properly.
>>>>
>>>> imo oak paths should always be normalized except for path values.
>>>
>>> Which means that we need to expose that in the path mapping API, right?
>>
>> In the sense I described above yes.
>>
>> Michael
>>
>