Serialization, deserialization, and construction of QuantityValue should treat the bound fields as optional. They can be omitted, be null, or empty strings to indicate unknown bounds.
TBD: if one bound is given, is the other bound then required?
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T56318 Quantity datatype (tracking) | |||
| Open | None | T133042 Quantity datatype precision (tracking) | |||
| Resolved | Lydia_Pintscher | T115269 [Story] When a Quantity is entered with no uncertainty/bounds given, do not guess uncertainty/bounds until needed. | |||
| Resolved | thiemowmde | T115270 Allow QuantityValue objects to have empty/no bounds set |
Event Timeline
Comment Actions
First draft:
To be discussed: How should the serialization look like?
- {"amount":"+1","unit":"1","upperBound":"+2","lowerBound":"+0"} is how it looks now when the user entered "1" and the parser guessed +/-1.
- {"amount":"+1","unit":"1","upperBound":null,"lowerBound":null} is what my patch suggests. Advantage: Minimal breaking change because the keys are always there. Disadvantage: Wastes space.
- {"amount":"+1","unit":"1"} is almost the same, but breaks consuming code faster. This could even be an advantage.
- {"amount":"+1","unit":"1","upperBound":"","lowerBound":""} was mentioned today. I do not like this.
Opinions?
Comment Actions
I personally prefer {"amount":"+1","unit":"1"}, following the idea that "if you break stuff, it should be obvious". {"amount":"+1","unit":"1","upperBound":null,"lowerBound":null} is not less of a breaking change, just less obvious. Client code that actually accesses the fields in question will stop working either way. Client code that doesn't touch these fields won't care either way.
That being said, I don't feel very strongly about it. And in any case, we should accept all the options as input.