[Wikidata-bugs] [Maniphest] [Commented On] T73170: Ensure feature parity of serialization based on WikibaseDataModelSerialization with what we do with WikibaseLib
daniel added a comment. We'd need at least: - Term with fallback (already exists) - Snak with DataType - Snak with extra DataValues (normalized/expanded) - Grouped StatementList and SnakList - Link, Term, Statement, etc with a deleted flag - LinkList, TermList, StatementList, etc with a filtered flag - Entities with secondary IDs (redirects) All of them should be acceptable for deserialization, but should not be acceptable input for EditEntity and friends, since the information is derived or imposed by filtering/sorting parameters. We can go this route, shifting some of the required changes from the serializer component to the datamodel component. But the serializers still need to support the new types, and we are still blocked on implementing all this before we can ditch the old serializer. On top of the above, we still need the serializer itself, or the ResultBuilder, to support: - empty maps (not lists) as objects - indexedTagName markers (I think post-processing is ok for this) - injection of version info - maintaining order of map entries TASK DETAIL https://phabricator.wikimedia.org/T73170 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: JeroenDeDauw, thiemowmde, Bene, Wikidata-bugs, Tobi_WMDE_SW, JanZerebecki, adrianheine, Lydia_Pintscher, daniel, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T73170: Ensure feature parity of serialization based on WikibaseDataModelSerialization with what we do with WikibaseLib
JeroenDeDauw added a comment. @daniel: I do not see how we need to be adding a second, rather complex, data model on top of the core data model. For the example provided, having a serialization of a property value snak with added data type, all you need is a simple typed snak object. One such value object is neither complex nor a duplication of the whole model, and much less icky than introducing interfaces for non-serialization services in a serialization component. Sure, code that relies on modes and switches is annoying. And serializers should be dumb. But if upholding these principles 100% causes a lot of overhead, we should probably go for a balance point closer to the energetic minimum... I'm not sure if that is meant to be a reply to anything I said. Just in case: I agree switches are not nice though that the most pragmatic trade-of will probably involve some. In fact, there already is one: https://github.com/wmde/WikibaseDataModelSerialization/blob/master/src/SerializerFactory.php#L50 TASK DETAIL https://phabricator.wikimedia.org/T73170 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JeroenDeDauw Cc: JeroenDeDauw, thiemowmde, Bene, Wikidata-bugs, Tobi_WMDE_SW, JanZerebecki, adrianheine, Lydia_Pintscher, daniel, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T73170: Ensure feature parity of serialization based on WikibaseDataModelSerialization with what we do with WikibaseLib
daniel added a comment. I have edited the description to remove the implication that *all* these features have to be implemented *inside* WikibaseDataModelSerialization. TASK DETAIL https://phabricator.wikimedia.org/T73170 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: JeroenDeDauw, thiemowmde, Bene, Wikidata-bugs, Tobi_WMDE_SW, JanZerebecki, adrianheine, Lydia_Pintscher, daniel, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
