Things that the old serializer supported (or should have supported), and need to be possible using the new model and serializer too:

• Filtering (terms by language, sitelinks by site, statements by rank)
• Apply language fallback (and put info about the fallback in the terms)
• optionally group claims by property
• optionally use lists instead of maps that use IDs as keys (to cater to the quirks of ApiFormatXml).
• deletion markers used in responses of API modules like RemoveClaim

In some cases, we want to (optionally) inject extra information into the serialization (or presentational model), e.g.:

• the DataType of PropertyValueSnaks
• (future) full URIs for external identifiers
• (future) quantity values converted to base units

We should try to avoid putting such "derivative" versions of our data back into the database, as this would constitute data loss and/or create confusion (especially in the case of automatic transliteration).

Another question is if and how "derivative" entity information can and should be represented by our data model. We should have a spec that makes a clear distinction between the "core" data model, and "representational" or "informational" derivatives.

PS: We also need a way to represent order explicitly when using id based maps instead of lists (for statements, qualifiers in a claim, references in a statement, and snaks in a reference). This is part of the core model, but was not addressed by the old serializer either.

Never mind #1, that was meant for bug 71170.