Operators gt, lt etc to enums too, that means that we are allowing to compare strings with lt, gt.... that not make sense

[RubenBG7]

If we read the API guidelines designed, we are applying operators gt, lt etc to enums too, that means that we are allowing to compare strings with lt, gt.... that not make sense.

In adition we are not allowing with the actual guidelines to compare a value that is exactly that value , we have not defined the equals operator. Then my proposal is basing on the TMF 630 use:

For numeric and dates value allow:

.gt > / .gte >= / .lt < / .lte <= / .eq = / .neq !=

And for string enums:

.eq = / .neq !=

[eric-murray]

The filtering examples already allow the = operator to be used to test equality for text (i.e. strings, whether enumerated or not), numbers and dates:

Operation	Text	Numbers	Dates
Equal	GET .../?name=Juan	GET .../?amount=807.24	GET .../?executionDate=2018-30-05

The question is whether the inequality operators (gte|gt|lte|lt) make sense for enumerated strings, which is currently allowed.

I had assumed this would be applied in the same way that programming languages treat enumerated types. So for enum: [ three, two, one ], then one is greater than two, which is greater than three. But this was just an assumption on my part, and certainly it could do with clarification, or the removal of the option to use inequality operators with enumerated types if this is not useful.

I have no problem with introducing a "not equals" operator (!= or .neq) or the additional equality operator .eq if these would be useful.