@@ -423,7 +422,71 @@ However, they are tailored to the specific data formats they are designed to sup
## 7.3.1 Enhancing the Existing *Filter Criteria* Method
<mark>Cyrille (Orange) contributes</mark>
The main limitation of the current filtering in oneM2M is the lack of recursivity, which forbids to express complex requests,
and the fact that only the OR logical operator can be used between matching conditions of the same type (i.e. attributes).
#### 7.3.1.1 Filter Groups
This first proposal therefore focuses on adding a new *filterGroup (fg)* matching condition that allows nesting expressions and enforces operations
pointed to by the *filterOperation (fo)* tag also between Filter Matching Conditions of the same type.
Making the operation type defined in *filterOperation* tag valid for all the Filter Matching Conditions both makes the syntax more clear/readable
and allows using all AND/OR/XOR/NOT operations also for attributes.
With this approach it is not only possible to apply different operations between attribute tags in general but also to use
different operations for each subsequent *filterGroup* when needed.
Example:
```xml
<filterCriteria>
<fo>2</fo>
<attribute> … </attribute>
<fg>
<fo>1</fo>
<labels> … </labels>
<childLabels> … </childLabels>
</fg>
<fg>
<fo>1</fo>
<attribute> … </attribute>
<fg>
<fo>2</fo>
<labels> … </labels>
<childLabels> … </childLabels>
</fg>
</fg>
</filterCriteria>
```
This example displays new possibilities to express complex requests:
- Multiple instances of *filterGroup* matching condition allowed.
-*filterGroup* matching conditions can be nested.
- Separate filtering operation defined for each *filterGroup* matching condition.
**Note**
It is also proposed to remove a quite confusing rule in TS-0004 7.3.3.17.0, saying that:
“If multiple matching conditions of the same type (i.e. same condition tag) are present in the Filter Criteria parameter,
these shall be combined by applying logical OR operation".
With the proposed extension,
- to send a disjunction request with multiple matching conditions of the same type, the *filterOperation* must be explicitely set to OR.
Though this brings a backward incompatibility, this is limited to matching conditions that originally had 0..n multiplicity,
that is: *contentType*, attributes, childAttributes, parentAttributes, *semanticsFilter*.
- it is allowed to use conjonctions (and XOR operations) requests with multiple matching conditions of the same type,
for instance on attributes (e.g. *attr1=val1 and attr2=val2*), which was not possible before.
#### 7.3.1.5 Advantages and Disadvantages
- Major increase in semantic expressiveness with minimal syntactic change: the syntax is the same as the existing one, with only one new filter criterium;
basically, it just allows nesting expressions of the existing request language.
- Easy to implement, for the same reason.
- A logical *not* operation is added inside the *filterGroup*.
<br/>
- It does not allow non-equality operations on attributes (it could be feasible, but complex to implement and costly at runtime).
- It does not extend path-based requests à la XPath/JSONPath (except current child/parent equality on labels and attributes).
- Possible break of backward compatibility if the rule on the default value of *fo* is removed (see the note above).
## 7.3.2 Defining a Simplified New Filter and Query Language
