|Yes of course. We would just have to come up with a JSON schema to express it but that shouldn’t be too difficult.|
I forgot to mention that we also talked about using parenthesis to control precedence more finely, but in JSON this would be easier to do by using the tree directly.
We can additional put that into a json tree to avoid the query parsing, or? The simplicity can be kept from my perspective.
This sounds interesting to me, and I believe the "shortversions" are most useful in terms of softening The transition from SQL, but a pure function language would be much easier to implement I guess?
What might we miss out on compared to regular WHERE statements?
Vennlig hilsen/Best regards
Yesterday Chris and I worked on specifying a query language for object-specific queries. We mostly focused on the profile queries, and came up with something relatively simple, although not extremely compact. Basically the syntax looks something like this :
[OPERATOR] FUNCTION OPERATOR FUNCTION
where function is something like
closeTo(propertyName, geoLocation, distance)
and OPERATOR is one of :
For example we can express something like : a profile between 30 and 60 and close to geneva with something like this
greaterThan(‘age’, 30) AND lessThan(‘age’, 60) AND closeTo(‘city’, ‘geneva’, 30000)
Chris mentioned it was a bit verbose but at the same time it is very simple to implement and use. We could imagine then supporting either shorter function names such as : eq, gte (greaterThanOrEqualTo), lte (lessThanOrEqual). We could even see if we wanted to support “shortcuts” so that we can use the <=, >= operators but these would simply get translated into function calls.
The nice thing about functions is that they can be extended by an implementation, meaning that implementations could provide more powerful functions. We could even imagine functions that would query other objects, in effect providing some sort of “application join” functionality.
We propose that we define a built-in set of core functions in the specification, and that we then leave the door open for extensibility.
Personally I like this proposal because it is a good compromise between simplicity and functionality, but of course we’d love to have your feedback.
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at: