Update TR-00070-Enhanced-filtering-and-queries.md: Orange proposal

TR-00070-Enhanced-filtering-and-queries.md

-
 ![oneM2M logo](media/logo.png)
 
 
@@ -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