General disagreement about content filter expressions and expression parameters #37
Description
Executable's name
- Publisher: opendds-3.27.0_shape_main_linux, connext_dds-6.1.2_shape_main_linux, eprosima_fastdds-2.13.3_shape_main_linux, toc_coredx_dds-6.0.0_shape_main_linux
- Subscriber: opendds-3.27.0_shape_main_linux, connext_dds-6.1.2_shape_main_linux, eprosima_fastdds-2.13.3_shape_main_linux, toc_coredx_dds-6.0.0_shape_main_linux
Reproducing the problem
- Test Suite: rtps_test_suite_1
- Test Case: Test_Color_0
- Link to the GitHub Action workflow run: NA
What is the problem?
- Publisher expected code: OK
- Publisher produced code: OK
- Subscriber expected code: OK
- Subscriber produced code: OK/DATA_NOT_RECEIVED
Suggestions about why this problem exists
The filter expression and expression parameter offered by the various subscribers is thus:
| Executable | Filter Expression | Expression Parameter |
|---|---|---|
| opendds-3.27.0_shape_main_linux | color = %0 | BLUE |
| connext_dds-6.1.2_shape_main_linux | color MATCH %0 | 'BLUE' |
| eprosima_fastdds-2.13.3_shape_main_linux | color = %0 | 'BLUE' |
| toc_coredx_dds-6.0.0_shape_main_linux | color = %0 | BLUE |
In the case of opendds as publisher and connext as subscriber, opendds does not support a MATCH operator so it performs no publisher-side content filtering, i.e., all samples are sent to the subscriber which then would filter again.
This is interoperable but probably not what is intended.
The reverse case succeeds.
In the case of opendds as publisher and eprosima as subscriber, the difference in quoting the parameter causes failure.
The reverse case succeeds.
opendds and coredx agree on the expression and expression parameter so both directions succeed.
I did not test other vendor combinations.
I suggest that the filter expression always be color = %0.
Expression parameters are defined in 2.2.2.3.3 and 2.2.2.3.4 as
The expression_parameters attribute is a sequence of strings that give values to the ‘parameters’ (i.e., "%n" tokens) in
the subscription_expression. The number of supplied parameters must fit with the requested values in the
subscription_expression (i.e., the number of %n tokens).
Annex B implies (clarification is needed) that an expression parameter corresponds to the Parameter non-terminal which can be either an INTEGERVALUE, CHARVALUE, FLOATVALUE, STRING, ENUMERATEDVALUE, or PARAMETER.
Logically, PARAMETER is excepted as the goal of a expression parameter is to supply a value for PARAMETER that appears in an expression as quoted above.
As it relates to the issue at hand, CHARVALUE and STRING require single quotes as delimiters.
This makes sense and is necessary when they appear in an expression.
However, expression parameters are conveyed through string sequences so the use of delimiters is superfluous.
Furthermore, it prevents using the single quote in an expression parameter.
I suggest that expression parameters not be quoted and DDS Specification be clarified on this point.
Thus, for this test, the expression parameter would be BLUE.