Page MenuHomePhabricator

Allow QuantityValue objects to have empty/no bounds set
Closed, ResolvedPublic


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?

Event Timeline

daniel raised the priority of this task from to Needs Triage.
daniel updated the task description. (Show Details)
daniel added subscribers: Aklapper, daniel.
thiemowmde triaged this task as Medium priority.
thiemowmde edited projects, added Patch-For-Review, DataValues; removed Wikibase-DataModel.

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.


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.

thiemowmde moved this task from Review to Done on the Wikidata-Sprint-2016-07-19 board.
thiemowmde removed a project: Patch-For-Review.