Page MenuHomePhabricator

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

Description

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 created this task.Oct 12 2015, 5:01 PM
daniel raised the priority of this task from to Needs Triage.
daniel updated the task description. (Show Details)
daniel added subscribers: Aklapper, daniel.
Krenair set Security to None.
Krenair added a subscriber: Krenair.
Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptNov 16 2015, 2:40 PM
thiemowmde triaged this task as Normal 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.

Opinions?

daniel added a comment.EditedApr 26 2016, 3:37 PM

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 closed this task as Resolved.Aug 1 2016, 1:43 PM
thiemowmde moved this task from Review to Done on the Wikidata-Sprint-2016-07-19 board.
thiemowmde removed a project: Patch-For-Review.
Lydia_Pintscher moved this task from incoming to in progress on the Wikidata board.Aug 2 2016, 9:00 AM