| 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.
cheers, Serge…
Hi guys, We can additional put that into a json tree to avoid the query parsing, or? The simplicity can be kept from my perspective. Jan 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
Hello guys,
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
equals(propertyName, propertyValue)
lessThan(propertyName, propertyValue)
greaterThan(propertyName, propertyValue)
closeTo(propertyName, geoLocation, distance)
and OPERATOR is one of :
AND
OR
NOT
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.
cheers,
Serge…
---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|