Last modified: 2014-11-13 11:30:53 UTC
Check if we could roll out statements on properties with the old serialization code in lib. Collect list of todos if is not possible right away.
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.
