Rudder

The json structure is organized like that:

"select" : mandatory value,  "node" or "nodeAndPolicyServer" 
    "composition": either "and" or "or". Optionnal, default to "and" 
    "where": an array of json objects composed of:
        "objectType": the kind of object to look for. They are all defined in https://github.com/Normation/rudder/blob/branches/rudder/3.0/rudder-core/src/main/scala/com/normation/rudder/domain/queries/DitQueryData.scala around line #280 (def objectTypes = Map... ). Some interesting ones:
            node : for all the OS, RAM, etc
            environmentVariable
            software
        "attribute": the name of the attribute to lookup for the given object. The possible names are defined in DitQueryData to: it's the huge list of "ObjectCriterion". Problem: most use name defined elsewhere in the form of "A_OS_VERSION" etc. The name are defined in one the two files:
            https://github.com/Normation/ldap-inventory/blob/branches/rudder/3.0/inventory-repository/src/main/scala/com/normation/inventory/ldap/core/LDAPConstants.scala
            https://github.com/Normation/rudder/blob/branches/rudder/3.0/rudder-core/src/main/scala/com/normation/rudder/domain/RudderLDAPConstants.scala
        "comparator": the kind of comparator to use:
            exits / notExists: only check the presence of that kind of attribute for the object in the node
            eq: equals
            notEq: not equals
            gt / gteq: greater than / greater or equals
            lt / lteq : lesser than / lesser or equals
            regex: match the given pattern. The authorized regex are the Java one, as defined in http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html
            notRegex : all entries not matching the given regex
            and there is a special syntax for key=value objects, like "environmentVariable". For them, you use the attribute "name.value", the comparator to use, with a new one:
                hasKey: to only check for the key part equals the given value
                else, the comparison is done on "key=value", and you can do almost anything with regex
                Ex: {"select":"nodeAndPolicyServer","composition":"And","where":[{"objectType":"environmentVariable","attribute":"name.value","comparator":"regex","value":".*NAME=r[o]{2}t"}]}

There is example in the tests for query:
https://github.com/Normation/rudder/blob/branches/rudder/3.0/rudder-core/src/test/scala/com/normation/rudder/services/queries/TestJsonQueryLexing.scala
https://github.com/Normation/rudder/blob/branches/rudder/3.0/rudder-core/src/test/scala/com/normation/rudder/services/queries/TestQueryProcessor.scala

So, if you read until hear, you now see that the current format is quite ad-hoc - or more preciselly, it reflects far to much the underlying storage format.
A more versatile version is think about, based on the JSON format of the node details returned by the API and a XPATH kind of query. But well, it's not for now, and the current language is already in the nature, so it will be supported :)
At least, in 3.1 we are going to try to normalize object and attribute names so that they match the names in the node details returned by the API.

Duplicate of #10299.