One VM, two syntaxes
In Zorba 2.6, we introduced JSON support with the new
JSONiq language.
JSONiq extends XQuery with JSON support while leaving its XML functionality (almost) intact. This came at the cost of either circumvoluted syntax for JSON (like empty objects, or object lookup), or for breaking some XML corner-case functionality (like true, false and null that are recognized as literals rather than as XPath name tests).We have received a lot of feedback since then, and realized that, for those of you who would like to work primarily with JSON, it made sense to let the
JSONiq syntax live its own life.Concretely, this means that: 1. The "virtual machine" (abstract query language, compiler and runtime) stays the same and fully support both XML and JSON. 2. But Zorba supports two syntaxes for it: XQuery and
JSONiq, which are each tailored to the aesthetics preferences of each community.
Two faces of the same language
To put it boldly, in terms of syntax, XQuery and
JSONiq can be seen as two faces of the same language.The XQuery syntax provides first-class XML support (full W3C conformance), as well as second-class JSON support ("JSONiq extension to XQuery" : everything
JSONiq that does not collide with XQuery).The
JSONiq syntax provides first-class JSON support (nice JavaScript-like dot-based object lookup, full JSON copy-and-paste support, etc) and second-class XML support ("XQuery extension to JSONiq" : everything XQuery that does not collide with
JSONiq).
Syntactic contentious points
Here is a more detailed description of the collisions between XML and JSON support.A.
Dots in NCNames vs. Dot-based object lookup. XML names can contain dots, but dots are also used for object lookup. In particular, $var.key can be interpreted as a variable named "var.key" or as a lookup in the object $var for the key "key".B.
Context item syntax. XQuery uses dots for the context item syntax. But combined with object lookup, it becomes hard to read: ..key for looking up the key "key" in the context item.C.
String literals. XQuery supports both single-quoted and double-quoted literals. JSON only supports double-quoted literals.D.
Character escaping. XML uses apersand-based escaping, like &#a; or &. JSON uses backslash-based escaping, like or \.E.
Object keys. In some JSON languages, simple object keys (containing no spaces, etc) may be unquoted. This collides with XPath name tests.F.
true, false and null literals vs. XPath name tests. In XQuery, booleans can be constructed with the functions true() and false(), because true and false would be recognized as name tests. In JSON data, true and false appear as literals.G.
Empty object vs. empty block syntax. In JSON, the empty object is denoted {}. In Zorba's scripting extension to XQuery, {} is used for the empty block.H.
Type syntax. XQuery supports user-defined atomic types. To avoid collisions, XML node types use parentheses: node(), element(), etc as well as namespaces: xs:integer, xs:string, etc.
JSONiq aims at a simpler syntax, with no parentheses: integer, string, object, array.I.
Update syntax. The XQuery update syntax collides with the JSON update syntax (insert, delete, replace, rename).
The JSONiq syntax
This syntax fully supports
JSONiq, as well as some aspects of the XQuery syntax.It is a superset of JSON (yes, you can copy-and-paste JSON data in a
JSONiq query). It is not a superset of XQuery.A. No names containing dots.B. No . for the context item - use $$ instead.C. No single-quoted literals. Use double-quoted literals instead.D. JSON, baskslash-based escaping in string literals (you can switch with an option).F. No axis step allowed at the beginning of a relative path expression. Instead of using foo:bar, you must use $$/foo:bar.G. {} is for empty objects. Use {;} for empty blocks.
