Sorting issues

[duglin]

I believe someone can define a model with this:

"attributes": {
  "age": {
    "type": "integer",
    "ifvalues": {
      "16": {
        "siblingattributes": {
          "school": { "type": "string" }
        }
      },
      "18": {
        "siblingattributes": {
          "school": { "type": "boolean" }
        }
      }
    }
  }
}

In general defining "school" to be of different types isn't an issue. However, what if they then try to sort by it?

GET ...?sort=school

What would the result be if sometimes it's a boolean and sometimes it's a string?

Some options:
1 - introduce some kind of constraints that would ban IfValues from having "same named" attributes of different types. But that seems overly restrictive
2 - sort all IfValue-defined attributes as strings regardless of their type
3 - sort IfValue-defined attributes as strings ONLY IF we detect this state. Not sure how easy it is to detect this, but also it means the sorting results will change as IfValues are added or removed. That inconsistency could be problematic.
4 - sort all attributes as strings.
5 - punt! It's probably an edge case and say that if the data type can not be determined then the results are indeterminate and each persistent store will probably have different results.

The obvious problem with sorting as strings is sorting numerics is then broken since "2" will come after "10".

I think a similar issue will pop-up when an attribute (or "*" extensions) are defined as "any".

[duglin]

I'd also like to change this sentence:

---

If more than one entity shares the same attribute value then the id MUST be used as a secondary sorting key, using the same asc/desc value specified for the primary sorting key.

---

to be:

---

If more than one entity shares the same attribute value then the id MUST be used as a secondary sorting key (ascending).

---

[duglin]

Then we have the NaN issue: #377

[duglin]

Proposal: Add this text:

Sorting MUST be done using the data type comparison rules as specified in the filter section. However, there are certain situations that might introduce ambiguity between implementations. For example, not all persistent stores support NaNs (non a numbers), or if the data type of an attribute changes on a per-instance basis then consistent sorting across implementations on that attribute might be challenging. While interoperability is critical, requiring consistency in these edge cases could be excessively burdensome for implementations. To that end, this specification does not mandate the exact ordering in these situations, aside from the requirement that an implementation MUST sort the result the same way each time.