Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of stefan.guggisberg@gmail.com
 designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EE8B8A4.1080009@apache.org>
References: <CB0E6933.2146C%mueller@adobe.com>
	<4EE8B052.9000306@gmx.de>
	<4EE8B8A4.1080009@apache.org>
Date: Wed, 14 Dec 2011 16:02:10 +0100
Message-ID: 
 <CAFYk8NkSwQvHLwCkHXiv-7Jekseqh7_3Ps81TQ6v6yr56ksXAA@mail.gmail.com>
Subject: Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
From: Stefan Guggisberg <stefan.guggisberg@gmail.com>
To: dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 14, 2011 at 3:54 PM, Michael D=FCrig <mduerig@apache.org> wrote=
:
> On 14.12.11 14:18, Julian Reschke wrote:
>>>
>>> The use case is that the client should have a way to detect the JCR dat=
a
>>> type for unstructured data (JSON doesn't have a 'date' data type). For
>>> the
>>> MicroKernel, we currently use a different convention: we encode the dat=
a
>>> type in the value.
>>
>>
>> <insert-anti-JSON-pro-XML-rant-here/>
>>
>> Maybe sometimes simple is too simple :-)
>>
>
> When we started using 'JSOP' and JSON for the jr3 Microkernel based
> implementation, we didn't have a clear picture on how to map things to JC=
R.
> The conception then was 'decorate it on top somehow'. As it is apparent f=
rom
> this discussion, this isn't as easy as it seems without resorting to ad-h=
oc
> extensions.

WRT 'copy': not simple? ad-hoc extension? to what? a non-existing specifica=
tion?

cheers
stefan

>
> This discussion just touched two of the paint points: copy and data types=
.
> Others are: observation, locking, name spaces and remapping, access contr=
ol,
> ordering, properties and nodes with the same name, same name siblings...
>
> Michael
>
>