Another productive Workgroup 3 session

[Serge Huber <shuber@jahia.com>]

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…