JSONiq | JSONiq Specification -

Finally, managed a way with JSONiq using Zorba implementation. Definitively the way to go if you need powerful JSON queries. Apparently this has been integrated in Apache Spark with Rumble

Anyway, here's my solution:

Zorba supports adding documents to a collection. The framework for doing so is documented here. Note, however, that Zorba is a memory store and will not persist anything beyond the scope of one query, so that this is of limited use without a persistence layer.

If the use case is simply to query a JSON file stored on your local drive, then it may be simpler to use EXPath's file module as well as parse-json, like so:

The core JSONiq language supports only JSON, in the same the core XQuery language supports only XML. However, there are many people who want to query both XML and JSON in the same program, for example to convert one to the other. This is why there are extensions (both ways). Rather than forbidden, I would say that they are optional (and actually encouraged).

If the data is a mix of JSON and XML, then you can use either the "JSONiq extension to XQuery" or the "XQuery extension to JSONiq." The differences are minor and revolve around convenience. Feature-wise, both are equivalent.

The exact differences are comprehensively documented here

A complete grammar with JSONiq, the XQuery extension and even updates and scripting is available here.

If there is a lot of JSON and a bit of XML, then "the "XQuery extension to JSONiq" is more adequate: you can query JSON with dots and escaping in strings is done with backslashes, and literals like null, true and false are recognized, but any XPath name queries on XML Names must be prefixed by ./ (./foo instead of just foo), etc.

If there is a lot of XML and a bit of JSON, the "JSONiq extension to XQuery" is more adequate. It is the opposite: the exact, W3C-compliant XPath syntax is supported and string escaping with ampersands, but for example booleans and nulls must be written as true(), false(), null() to not interfere with XPath.

The Zorba engine supports both of the variants, and you can switch using xquery version "3.0" or jsoniq version "1.0" in the header of the query, with no further configuration: if you use JSONiq, the XQuery extension is always available as well, and if you use XQuery, the JSONiq extension is always available.

If no header is present, then the extension .xq or .jq is used to infer the language used.

Whether or not a JSONiq processor supports the XQuery extension is a decision of the software provider. In general, we encourage implementors of a JSONiq engine to support the XQuery extension if they have the resources. Providers who want to keep a very lightweight engine will stick to core JSONiq.

The other way round, extending an existing XQuery engine with the JSONiq extension is very easy: when we did so in Zorba when we started supporting JSON, it only took us a few days because the JSON data model is so simple. There is a talk by Jonathan Robie sharing experience on this topic on Youtube.

JSONiq is an XQuery-like language for processing JSON. Most of its good ideas were incorporated into XQuery 3.1, but in a way that integrated the XML and JSON data models. I don't believe JSONiq offers any functionality that's not in XQuery 3.1, and it's not an open standard, so there would be little point in implementing it in Saxon.

visit also is an array, so you need the parenthesis to get to the individual visits in the for. This

The following selection works for me at the site you linked to:

Zorba can query not only the local file system, but also any documents stored in a way accessible via a REST API.

First, Zorba provides a few built-in modules to connect to Couchbase, SQL databases, etc

http://www.zorba.io/documentation/latest/modules/connectors

Second, support for more stores can be implemented using the REST module:

http://www.zorba.io/documentation/latest/modules/zorba/io/http-client

For each new document store to be supported, it is common to create a new user-defined module that wraps the REST calls into a JSONiq module API that mimics that of a document store, in a way that maps naturally to the underlying REST API (e.g., connect, get, put, update, delete, ...). The parameters of this module's functions can be JSON objects or XML documents almost identical to those actually passed as content/body to the REST API (e.g., query by example).

With knowledge of the module syntax, this usually takes about 1000 lines of code and a few days to do, and if applicable can easily be shared with other users for example on GitHub as it is mostly a single module file. Some such modules may be available online.

It should also be said that Zorba supports the standardized EXPath HTTP client as well (similar to the other one, but with general parameters passed in XML format instead of JSON). This means that any modules designed to query XML-based document stores should even be interoperable with XQuery/JSONiq engines besides Zorba.

Document stores that do not support REST can also be supported, but this requires C++ coding and is significantly more involved.

Since you mention scaling up, I should also mention Sparksoniq, which scales up to query JSON data (tested up to a few billion objects) stored on HDFS.

I hope this helps you further.

I planned initially to iterate over an array of objects to print out the data within the objects. For JSONIQ, I discovered that I needed to parenthesize the array name which is book() in this case.

My code below should iterate over, the title, the author, and the price of the book.

Yes: the trace function serves this purpose. It can be called on any expression of which one needs to see the output, together with a label of your choice.