daniel added a comment.
@JeroenDeDauw In theory, you are right: the serializer should just serialize
whetever they are given. In practice, this means adding a second, rather
complex, data model on top of the core data model, or complicating the core
data model. That's a lot of work, and the
daniel added a comment.
@JeroenDeDauw You can also see it this way: feature parity is for
model+serializer. If we move all the options and modes into the model, we need
something to build the output model from the core model, and that converter
thing would need to do all the things described
JeroenDeDauw added a comment.
It seems like a bunch of blockers where added that have little to do with
feature parity between the current code in Lib and the Wikibase DataModel
Serialization code. I recommend to keep moving away from the legacy code and
implementing new functionality
JeroenDeDauw added a comment.
Keep in mind that serializers take the thing to serialize and give you the
serialization of that thing. And nothing more. You could construct an entity
serializer that takes an entity id and then fetches the entity. This fetching
is an added and misplaced
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.
