JSON Query starting questions
Kris Zyp
be desirable for the fundamental structure of a JSON query language. I
have done working in creating a query language for Dojo and Persevere,
but I want to refrain from assuming that what I have done is really the
direction others feel should be taken for a JSON query language. A
future JSON query language can take any form, albeit we certainly have
the experience of some different attempts in this field to draw from.
It is certainly likely that the form will be largely shaped by the
requirements [1], so if there are requirements listed that do not seem
important, or requirements that should be included, feel free to speak
up about that. This is the foundation of the language development.
One of the first issues regarding the formation of the basic syntax
structure is how to represent the data sources that are being queried in
the query language. SQL represents data sources by using a namespace
with table names that can be referenced from in the queries. In
JSONPath, a single data source (the data set passed to the JSONPath
function) is referred to by "$". When using queries with in a URI (for
RESTful queries), one can naturally treat the path part of the URI (or
all the URI proceeding the "?", before the query portion), as the
representation of the data source, with the query operating on it. It
seems optimal that a JSON query language could be used in all these
situations. The last two situations, as well as attempting to have
similar syntax to EcmaScript, was the primary motivation for the
progressive operator style structure, that was suggested in the
requirements, enabling queries of the form:
<data source> <operatorA> <operatorB> ...
where operatorA acts on the data set from the data source, and operatorB
acts on the data set which was the result of operatorA's querying, and
so on.
If the requirements are acceptable, another of the primary questions
would be what constructs from JSONPath and EmacScript should be borrowed
for the language (and it might be worth considering some similitude with
application/x-www-form-urlencoded). I would think the intersections
would certainly be the strongest starting candidates:
<data>.propertyName ex: $.foo
<data>[propertyNameExpression] ex: $['foo']
Other interesting operators from JSONPath are the slice operator [0:4]
and the filter expression [?(@.foo='bar')].
One construct from EcmaScript that I think may be particular useful
would be the method call syntax. This would provide a highly extensible
structure that can be used for a wide variety of operations. For example:
$.sum()
And we could potentially leverage existing EcmaScript Array.prototype
functions:
$.filter(...)
$.slice(0,4)
And JSONPath operators like the slice operator and filter could possibly
be sugar for these semantics.
[1] http://groups.google.com/group/json-query/web/json-query-requirements
Kris
--
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com