Re: [cxs] Another productive Workgroup 3 session

[Thomas Sigdestad <tsi@enonic.com>]

Hi all!

Workgroup 2 just had a _very_ productive meeting (after som postponed ones) :-)

Interesting stuff to see from WG3 - and especially liked Serge’s touch at the end there! It seems brilliant. We have attempted to apply this in our work too.

While we’re at it we propose an even simpler DSL for the query, why not simply drop the whole “function” and “arguments” thing and just go for a function:[args] pattern?

{

and:[{

geoDistance:[{

geoLocation : 'x',

distance : 'y', }]

},

{

in:[1,2,3]

 }]

} 

‌‌

This is basically the same, but leaner syntax!

BTW: Using functions to create the entire query language is supposedly used elsewhere too :-). I will try to get some links

Also, we have opinions on the following:

* We should not use POST for queries but GET, as this is much more obvious - cleanly using POST to create and GET to, well get data.

* We think the complex stuff (query, sorting?) modelled as JSON should be sent in the body (this is how Elasticsearch does it, and it looks nice)

* Simple parameters such as offset, pageSize and maybe parameters to return should be plainly sent in the querystring, so one can easily access data even without using the body parameter and complex JSON stuff?

Check out the swagger file for the /events/ api endpoint. (sorry, just committed, no pull req this time!)

Finally - we are very skeptical of a generic /query endpoint - we prefer that each endpoint (events/ profiles/ etc) rather enable passing a query object to them - so you will never have to worry about what will be returned and how to make it work.

Vennlig hilsen/Best regards

Enonic AS

Thomas Sigdestad

CTO

On 23 Jun 2016, at 09:33, Serge Huber <shuber@jahia.com> wrote:

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…


---------------------------------------------------------------------
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