JSON pointer

[Andrei Neculau]

A bit outside the JSON-schema domain, but closely related:

Trying to decide of a syntax to reference a nested property (for an API), and looked at

JSONpath http://goessner.net/articles/JsonPath/

and of course JSONpointer http://tools.ietf.org/html/draft-pbryan-zyp-json-pointer-02

1. I wonder - what was the reason to choose this XPATH-like notation /object/property , instead of the closer-to-JavaScript dotted notation object.property ?

2. Am I missing the description of how to reference a numeric string?

/array/0 = first item of the array

/object/a = object.a

?? = object['0']

Thanks

[Francis Galiegue]

Hello,

On Tue, May 29, 2012 at 7:25 PM, Andrei Neculau
<andrei....@gmail.com> wrote:
> A bit outside the JSON-schema domain, but closely related:
>
> Trying to decide of a syntax to reference a nested property (for an API),
> and looked at
> JSONpath http://goessner.net/articles/JsonPath/
> and of course
> JSONpointer http://tools.ietf.org/html/draft-pbryan-zyp-json-pointer-02
>

Actually, the link to the current specification is this one:

http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-01

It is _very_ different to the link above.

> 1. I wonder - what was the reason to choose this XPATH-like notation
> /object/property , instead of the closer-to-JavaScript dotted notation
> object.property ?

Exactly for avoiding to fall in the trap "JSON <=> JavaScript". JSON
may have JavaScript in its acronym, its format is designed to be
language-independent.

> 2. Am I missing the description of how to reference a numeric string?
> /array/0 = first item of the array
> /object/a = object.a
> ?? = object['0']
>

The same pointer will be used in either case. If you want to access
the first element of:

{
"x": [ "a", "b", "c" ]
}

or the property labeled "0" of:

{
"x": {
"k1": null,
"0": "a"
}
}

the JSON Pointer will be #/x/0. It is up to implementations to
correctly account for the fact that whatever is after #/x (if
anything) is an object or an array. And of course, it may very well
lead to a "dangling" pointer, which implementations must also account
for ;)

Hope this helps,
--
Francis Galiegue, fgal...@gmail.com
"It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries" (Stéphane Faroult, in "The
Art of SQL", ISBN 0-596-00894-5)

[Andrei Neculau]

I see.

There's an "interesting" side-effect not differentiating between objects and arrays. One has to parse level by level, rather than just doing (ie. for JavaScript) "eval(root + JSONpointer)". If you're on the "eval is evil, no matter what" side, you'll love it.

As for trying to make JSONpointer "language independent" - my opinion might not matter, but the fact that one can do a simple eval("object=" + JSON), doesn't make JSON any less language dependent. The only thing that was achieved was to make it as hard for JavaScript as for any other language to parse a JSONpointer.

Thank you, Francis!

[Francis Galiegue]

On Tue, May 29, 2012 at 9:31 PM, Andrei Neculau
<andrei....@gmail.com> wrote:
> I see.
>
> There's an "interesting" side-effect not differentiating between objects and
> arrays. One has to parse level by level, rather than just doing (ie. for
> JavaScript) "eval(root + JSONpointer)". If you're on the "eval is evil, no
> matter what" side, you'll love it.
>
> As for trying to make JSONpointer "language independent" - my opinion might
> not matter, but the fact that one can do a simple eval("object=" + JSON),
> doesn't make JSON any less language dependent. The only thing that was
> achieved was to make it as hard for JavaScript as for any other language to
> parse a JSONpointer.
>

JavaScript is not the only language to have eval, but that's not the
matter at hand here. It is not that there is any effort in ' trying to
make JSONpointer "language independent"', JSON _itself_ is language
independent. It was only logical that a mechanism to address any
"path" into a JSON instance also be designed to be language
independent. If it weren't, that would be a severe step backwards,
wouldn't it?

As to implementing it being hard... I don't know JavaScript but it
really doesn't seem that hard to me.

[Andrei Neculau]

On Tuesday, May 29, 2012 9:52:01 PM UTC+2, fge wrote:

On Tue, May 29, 2012 at 9:31 PM, Andrei Neculau
<andrei....@gmail.com> wrote:
> I see.
>
> There's an "interesting" side-effect not differentiating between objects and
> arrays. One has to parse level by level, rather than just doing (ie. for
> JavaScript) "eval(root + JSONpointer)". If you're on the "eval is evil, no
> matter what" side, you'll love it.
>
> As for trying to make JSONpointer "language independent" - my opinion might
> not matter, but the fact that one can do a simple eval("object=" + JSON),
> doesn't make JSON any less language dependent. The only thing that was
> achieved was to make it as hard for JavaScript as for any other language to
> parse a JSONpointer.
>

JavaScript is not the only language to have eval, but that's not the
matter at hand here. It is not that there is any effort in ' trying to
make JSONpointer "language independent"', JSON _itself_ is language
independent. It was only logical that a mechanism to address any
"path" into a JSON instance also be designed to be language
independent. If it weren't, that would be a severe step backwards,
wouldn't it?

XPath is language independent, correct? but it still has "/store/book[1]/title"

JSON is language independent, correct? but it still makes a difference between arrays and objects.

Same way Crockford said that in JSON, an object is denoted by {} and array by [], the JSONpointer could denote that to reference an item of an object you use a ".", and for an item of array, you use "[_]". What would be the biggie?

 

As to implementing it being hard... I don't know JavaScript but it
really doesn't seem that hard to me.

Didn't say that. I rephrase from

The only thing that was 
> achieved was to make it as hard for JavaScript as for any other language to 
> parse a JSONpointer.

to

The only thing that was 

> achieved was to make it as easy for JavaScript as for any other language to 
> parse a JSONpointer. 

[Francis Galiegue]

On Tue, May 29, 2012 at 11:46 PM, Andrei Neculau
<andrei....@gmail.com> wrote:
[...]

>
> XPath is language independent, correct? but it still has
> "/store/book[1]/title"
> JSON is language independent, correct? but it still makes a difference
> between arrays and objects.
> Same way Crockford said that in JSON, an object is denoted by {} and array
> by [], the JSONpointer could denote that to reference an item of an object
> you use a ".", and for an item of array, you use "[_]". What would be the
> biggie?
>

The biggie is that all of the following are valid property names in a
JSON object:

* "0"
* ""
* "/"
* "."
* "[0]"
* "/store/book[1]/title"

So, using array subscripting is just not doable. JSON Pointer as it
stands today can address each and every of these. JSON Path cannot.

BTW, JSON Pointer uses ^ to escape itself and /, so addressing
property "/store/book[1]/title" leads to a reference token of
"^/store^/book[1]^/title" in the JSON pointer.

[Andrei Neculau]

Touché!

My instinct was to reply with

of course it would, you would just write the path as object['/store/book[1]/title']

But at that point, that would indeed be language dependent - it's already JavaScript knowledge imposed on other parsers.

NB. I don't even know if JSON path has any rule like "if the property name is <special>, then refer to the object as an array, and enclose the property in quotes". It was a pure JS-inspired path.

Thank you, Francis

[Francis Galiegue]

On Wed, May 30, 2012 at 12:20 AM, Andrei Neculau
<andrei....@gmail.com> wrote:
> Touché!
>
> My instinct was to reply with
>
> of course it would, you would just write the path as
> object['/store/book[1]/title']
>
>
> But at that point, that would indeed be language dependent - it's already
> JavaScript knowledge imposed on other parsers.
> NB. I don't even know if JSON path has any rule like "if the property name
> is <special>, then refer to the object as an array, and enclose the property
> in quotes". It was a pure JS-inspired path.
>

Well, ultimately, JSON Path and JSON Pointer don't have the same goal.
The latter is really meant to address subnodes individually, JSON Path
addresses several.

I may give JSON Path a try (in Java) after I'm finished with JSON
Schema... That may be "fun"...

>
> Thank you, Francis
>

You're welcome!

Have fun,