jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Encoding of JCR values in json
Date Fri, 13 Apr 2012 11:43:17 GMT

On Thu, Apr 12, 2012 at 11:46 PM, Michael Dürig <mduerig@apache.org> wrote:
>> [value.equals(Long.valueOf(value).toString())]
> That's the approach I used in spi2microkernel. However, it has the drawback
> that we need to try catch through the cases when using the valueOf methods
> for determining the exact numeric type. Or we write our own code for
> parsing...

We need a JSON parser in any case, so that's probably the best place
to take care of this.

>> [infinities and NaN values]
> Ack. Either way is fine with me.

I suggest we choose to not support such values for now. If it later
turns out that support for them is needed, it should be fairly
straightforward to implement using the typing mechanism we in any case

>> * The explicit encoding of numeric constants from JCR seems a bit
>> troublesome and makes potential extensions more cumbersome.
> What extensions come to mind?

For example some applications might well want to be able to store
things like coordinates (think of geospatial search) as individual
scalars instead of collections of properties. Or there might be a
desire to have a custom property type for say email addresses or phone
numbers just like we have one for URLs in JCR 2.0. Or there could be a
need for storing date and time values separately instead of the
current timestamp values used in JCR. We don't have a current need for
things like these, but a future JCR version or another standard or use
case we want to support might well change that. Having an extensible
typing mechanism makes implementing such things easy.

>> * The overloading of normal strings requires that all string values
>> will need to be checked for whether they need to be escaped.
> That's a small penalty:
>  if(s.length() >= 2 && s.charAt(1) == ':') { ... }

Yep, it's not too big a deal, though there is a conceptual step from
"no escaping" to "some escaping".

> The trouble with that is, that type info and value are spread across
> different properties. Setting a JCR property requires two JSON diff
> operations here.

I don't think that would be too troublesome since the standard string
and number formats cover the majority of properties.

> Worse for JCR observation: the corresponding set property entries
> might be spread across the journal.

I'm not sure I follow. You mean a case where the value is set in one
revision and the type in another? That should be interpreted as two
setProperty() operations, each with different value types.

> So there are three different approaches now: 1) encoding the type into the
> value, 2) encoding it into a separate property, or 3) encoding it into the
> name of the property.

Microsoft chose a fairly smart variant of 1 for ASP.NET, see

For us that would mean something like this:

      "another long":"\/Long(124)",
      "another string":"/string"

The only trouble is that for this to work we need to require the
MicroKernel to keep track of the exact character sequences instead of
just the logical, unescaped strings. Currently this indeed is the


Jukka Zitting

View raw message