[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Another productive Workgroup 3 session
Hi guys, We had another productive session with our Workgroup yesterday, and I just wanted to update you with the highlights, as well as propose an idea I had this morning that’s sorta fun (and hopefully not scary :)) First of all, Chris came up with an EBNF grammar for the simple query language that we had discussed previously. He committed it here : https://github.com/sergehuber/contextserver-rest-api/blob/master/query-ebnf.txt Fortunately he didn’t spend a lot of time on it, since he used a tool he found online to see the results visually, you can find it here : http://www.bottlecaps.de/rr/ui I saw fortunately because I like Jan’s idea of using JSON to express the language instead of a single string but I’ll get back to that at the end of this mail. We worked on the Swagger file some more, and especially decided to split the queries on a single object type into two request types seperated by HTTP method : - GET : simple queries only, mostly propertyName=propertyValue type, where propertyName and propertyValue may (implementation specific) allow for wildcards or regular expressions (we could discuss making this a requirement or not). This was chosen because we were not confortable with using JSON queries in a GET request, wanted to allow for simple GET queries still. These queries could be very useful for auto-completion for example. We also allow for reverse ordering and properties selection on this method. - POST : complex queries. We didn’t have time to get into the details because we spent a lot of time working on the GET query, but the idea is that here we will use a JSON body to express the query and it’s parameters. You can see the beginning of this in the Swagger file. I personally really like this separation, and I think we should make sure that we homogenize this format throughout the object types, so this is why I’m writing this so that Workgroup 2 can get the latest developments. Now the fun part. I was thinking about the JSON format. If you remember we had somethink like this : function1(arg1, arg2, arg3) AND function2(arg1, arg2, arg3) …. Now if I try to express that in JSON it will look something like : { "operator":"AND", "subClauses":[ { "function":"function1", "arguments":[ "arg1", "arg2", "arg3" ] }, { "function":"function2", "arguments":[ "arg1", "arg2", "arg3" ] } ] } That’s a little lengthy and then I realize why seperate operators and functions ? Couldn’t an operator simply be a pre-defined function ? So in effect we can now express this like this : { "function":"AND", "arguments":[ { "function":"function1", "arguments":[ "arg1", "arg2", "arg3" ] }, { "function":"function2", "arguments":[ "arg1", "arg2", "arg3" ] } ] } We could maybe even simplify it some more but we might sacrifice space against legibility. I like the simplicity and power of it, of course we would have to define built-in functions that would become reserved function names but I thank that should be acceptable. What do you think of this ? cheers, Serge…
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]