Scope creep in a misguided attempt to make XQuery as relevant to JSON as it is to XML?  Or valuable additions that really make XPath and XSLT into dialects of LISP?  Why not both!

W3C XPath 3.1 came out in late March, and adds two features to XPath 3.0 in order to support JSON conversions to XDM better. This seems to be to support JSON data parsed into an XPath Data Model, rather than some JSON-in-XML hybrid.

Maps and Arrays

The two features are maps (unordered associative arrays) and arrays. They can nest. They are accompanied by four import/export functions: parse-json(), json-doc(), json-to-xml(), xml-to-json()

There is some new syntax for accessing them:

  • You construct a map with  map { key : value, ... }  where keys and values can be any XDM type, noting that you need spaces around the “:” to prevent any interpretation as namespace prefixes if they are names.
  • You can access items in a map using  $my-map[ ?key=value ]   There is a shortcut  $my-map( key )
  • You construct an array with array { value, ... }  where the value can be any XDM type, including elements or functions that are evaluated. There is a short cut,  of just [ value, ... ]
  • You can access items in an array with $my-array( n )  The access functions allow multiple values to be returned.

As well, there is a map operator !  and a lookup operator ?  which have more complex capabilities. The map operator !  is a replacement for the / location step separator, with the difference it does not enforce document order.  So it is more like an SQL SELECT keyword that lets you select data to have in a particular order, such as

person/name!@first, @middle, @last)

I liked the detailed summary at Altova for the new associated functions, like head() and tail().

LISP?

So the interesting question is how close are XPath or XSLT coming to being a LISP dialect?

The ability to have array of arrays obviously makes LISP lists easier.  The XPath 3.0 function evaluate() allows a constructed XPath to be evaluated.  The XPath 3.0 function transform() allows XSLTs to be run as a function inside an XPath.  Both these are very intriguing for single-pass Schematron support.  XPath 3.0 has an apply() function that takes a function name and applies it to the arguments.  Neither XPath nor XSLT (as far as I know) support what we might think of as anonymous lambda expressions as such: there is no node type for function bodies. Nevertheless 30 years ago, I would have said that a language with lists, eval, apply and the ability to go from external string form to internal object form was undoubtedly a LISP dialect.

Function pipelines

A footnote: Xpath 3.1 also includes the syntactic sugar pipeline operator  =>  along the same lines as many modern programming and scripting languages; instead of  a(b(c))) you can go  c => b => a