daniel added a comment. @mkroetzsch You are raising valid points, and we have been over them a few times in the last weeks. I'll try to briefly explain why we decided against some approaches:
- core model class knows about all optional information: it pollutes the main model, and forces additional dependencies on the data-model component. It's not extensible (e.g. WikidataQuality has no place to put constraint violation info on Statements). - use lookup services in the serializer and renderer: that was actually a strong contender, and would work well enough for output. But when loading and deserializing data that contains extra information, the deserializers have no place to put it. It would have to be returned to the caller via some side channel. That's confusing and unintuitive, and especially bad for the "consumer" side, which will often be a 3rd party. The role object isn't a particularly elegant solution. But all things considered, it seems the best compromise. It gives us the flexibility and modularity we need while keeping the code straight forwards and the information flow obvious. TASK DETAIL https://phabricator.wikimedia.org/T118860 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: mkroetzsch, adrianheine, hoo, thiemowmde, aude, Jonas, JanZerebecki, JeroenDeDauw, Aklapper, StudiesWorld, daniel, Wikidata-bugs, Mbch331 _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
