Wildcards in JSON object/array selectors.

[joel.depooter]

Hello again zorba folks,

I'm wondering if there is any plan to implement wildcards in the JSON object and array selectors, for example:

$json_array(*) - get all the values in an array
$json_object(*) - get all the values in an object
$some_object("results")(*) - get all the values in the value of the "results" object key
$array_of_objects(*)("name") - for each object in an array, get the value of the "name" key
etc

To my mind, this is similar to the xpath syntax: some-element/*/some-other-element.  I realize this can be done using the jn:members and jn:value functions, but a wildcard would allow much cleaner syntax.  It would allow me to remove function calls and loops, and keep a simple "path" concept.

The reason I ask, is I have previously implemented my own JSON path syntax, which is remarkably similar to the JSONiq syntax, except that I have support for wildcards.  I'm trying to change my old code to use JSONiq, but would like users to be able to use the same syntax as before.

At the moment, my current plan is to simply re-write a wildcard selection using a map operator, as follows:
(*) ==> ! local:json-values(.)

local:json-values is a function which returns the values in the passed in object or array.

$json(*) ==> $json ! local:json-values(.)
$some_object("results")(*) ==> $some_object("results") ! local:json-values(.)
$array_of_objects(*)("name") ==> $array_of_objects ! local:json-values(.) ("name")

Any comments as to the feasibility or performance of this type of query?

-Joel

[Ghislain Fourny]

Hi Joel,

Many thanks for your e-mail! We are very glad to receive and read this kind of feedback.

The short answer is: we do have a discussion on the table about XPath vs. JSON.

Our original design goal in JSONiq was to keep the language minimalistic and simple, extending syntax for core functionality such as array and object constructors (reusing the already existing dynamic function call syntax for navigation) and using function libraries for everything that can be implemented on top of the core.

Of course, we knew that this does not exclude a future evolution of the language - on the contrary, such modifications can be made adaptively and depending on user experience.

Since JSONiq supports XML as well (it is based on XQuery), the XPath syntax is already in the grammar, but currently throws errors when used on something else than XML nodes. An interesting area we are exploring would be to relax a subset of this powerful syntax to work on JSON objects and arrays.

Your examples would correspond to something like:
$json_array/*
$json_object/*
$some-object/results/*
$array_of_objects/*/name
etc

but also $json_object//* to reach all descendants, etc.

Note that unquoted paths like /results would be limited to a subset of JSON strings, but the ("results") notation could still be used with the entire JSON string space.

What do you think? Would this be something that addresses your needs?

Regarding performance, in a few words: if we do choose to use the XPath syntax, there is a lot of optimization experience gained with XML that is very likely to make sense with JSON as well.

Does it make sense?

Thanks and kind regards,
Ghislain

> --
> You received this message because you are subscribed to the Google Groups "Zorba Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to zorba-users...@googlegroups.com.
> To post to this group, send email to zorba...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msg/zorba-users/-/cfnOd2VKd18J.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
Dr. Ghislain Fourny
Software Architect

28msec Inc.

http://www.28msec.com
http://twitter.com/28msec

[Ghislain Fourny]

Hi Joel,

For completeness:

We also have on our investigation list the notations $object() and $array() with the semantics that you suggest under (*).

Using a star as you suggest already is valid JSONiq syntax, but has different, XML-related, semantics (= calling a unary function with the child nodes of the context node):

let $object := { "foo" : "bar" }
let $node := <node><child>foo</child></node>
return $node/$object(*)

returns "bar".

Does it make sense?

Kind regards,
Ghislain