daniel added a comment. In https://phabricator.wikimedia.org/T73170#1282773, @thiemowmde wrote:
> - Did the old serializer "include the property data type in > Property(Value)Snaks" and how did it do that when the new serializer can't? Yes, SnakSerializer gets a PropertyDataTypeLookup injected. > - "ditch the ungrouped representation" means a breaking change, right? Ditching this option is mentioned as an alternative to maintaining full party, namely, offering an api parameter to switch between the grouped and ungrouped mode. > - "we need to make that order explicit" means introducing a new feature that > currently does not exist in the serialization, right? I think we had that at one point, but I'm not quite sure. It's an aspect we should keep in mind though. > - Is "inject revision info" something the old serializer does and how does it > do that? ResultBuilder injects this into the ApiResult. It would be nice to integrate this better with serialization, but it's not technically a blocker. > - "deletion markers" are another non-existing feature, right? How is this > relevant for this ticket? We do this at least for removed sitelinks, see ResultBuilder::addSiteLinks, using EntitySerializer::OPT_PARTS, => "sitelinks/removed". I seem to recall we did this in more places. We also already do normalized/expanded data, with EntitySerializer::OPT_PARTS => "sitelinks/urls" > As discussed I'm arguing that the serializers are creating a specific > serialization anyway and adding some knowledge about markers (as strings, not > as an actual MediaWiki dependency) is ok in my opinion. Yes, incorporating some "magical" knowledge may not be the cleanest, but i nthe end the sanest way to go about this. Though I'm still considering post-processing for injecting the indextTagName stuff. TASK DETAIL https://phabricator.wikimedia.org/T73170 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: 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
