Change Details

(Description updated after a discussion between Jan, Katie, Thiemo, and Daniel 2015-05-11) WikibaseDataModelSerialization does not currently support all features the old serializers in WikibaseLib supports. In particular: * include the property data type in Property(Value)Snaks * grouped vs ungrouped output of Statements, Qualifiers, and Reference Snaks. * forcing (some) maps to lists (currently, there is an option to force maps to objects - that should probably always be done, to avoid issues with the representation of empty maps in JSON). * injecting "indexTagName" and other meta-info for the MediaWiki API serializer. Hard coded knowledge about these markers could be kept out of the serializer by using some sort of callback logic. * maintain ordered maps: since JSON does not specify the order of entries in a map, we need to make that order explicit, since it should at least be stable. * inject revision info (revision id, timestamp, page title). This is mediawiki specific, the serializer shouldn't know the meaning of such meta-data fields. * deletion markers for deleted elements in API responses. We may want to implement this by representing deletions in the DataModel somehow. Additional features we want to support in the future, but should already consider when thinking abotu a solution for the issues above: * Derived values in Snaks (normalized quantities, expanded external IDs, etc). Could be represented in the model in a way similar to TermFallback: ExtendedPropertyValueSnak would extend PropertyValueSnak (and perhaps implement a marker interface, to safeguard against serialization into the database). Note: derived values should not be supported as input to EditEntity, etc. * Filtered representations (terms filtered by language, sitelinks filtered by family or language, etc). Filtering can be done before serialization, but should be marked in the data model and in the serialization, to avoid data loss during round trips. * Represent incoming redirects as "secondary ids" in the serialized entity data structure (T98039)

(Description updated after a discussion between Jan, Katie, Thiemo, and Daniel 2015-05-11) WikibaseDataModelSerialization does not currently support all features the old serializers in WikibaseLib supports. In particular: * include the property data type in Property(Value)Snaks * grouped vs ungrouped output of Statements, Qualifiers, and Reference Snaks. * forcing (some) maps to lists (currently, there is an option to force maps to objects - that should probably always be done, to avoid issues with the representation of empty maps in JSON). * injecting "indexTagName" and other meta-info for the MediaWiki API serializer. Hard coded knowledge about these markers could be kept out of the serializer by using some sort of callback logic. * maintain ordered maps: since JSON does not specify the order of entries in a map, we need to make that order explicit, since it should at least be stable. * inject revision info (revision id, timestamp, page title). This is mediawiki specific, the serializer shouldn't know the meaning of such meta-data fields. * deletion markers for deleted elements in API responses. We may want to implement this by representing deletions in the DataModel somehow. Additional features we want to support in the future, but should already consider when thinking abotu a solution for the issues above: * Derived values in Snaks (normalized quantities, expanded external IDs, etc). Could be represented in the model in a way similar to TermFallback: ExtendedPropertyValueSnak would extend PropertyValueSnak (and perhaps implement a marker interface, to safeguard against serialization into the database). Note: derived values should not be supported as input to EditEntity, etc. * Filtered representations (terms filtered by language, sitelinks filtered by family or language, etc). Filtering can be done before serialization, but should be marked in the data model and in the serialization, to avoid data loss during round trips. (T73170) * Represent incoming redirects as "secondary ids" in the serialized entity data structure (T98039)

(Description updated after a discussion between Jan, Katie, Thiemo, and Daniel 2015-05-11) WikibaseDataModelSerialization does not currently support all features the old serializers in WikibaseLib supports. In particular: * include the property data type in Property(Value)Snaks * grouped vs ungrouped output of Statements, Qualifiers, and Reference Snaks. * forcing (some) maps to lists (currently, there is an option to force maps to objects - that should probably always be done, to avoid issues with the representation of empty maps in JSON). * injecting "indexTagName" and other meta-info for the MediaWiki API serializer. Hard coded knowledge about these markers could be kept out of the serializer by using some sort of callback logic. * maintain ordered maps: since JSON does not specify the order of entries in a map, we need to make that order explicit, since it should at least be stable. * inject revision info (revision id, timestamp, page title). This is mediawiki specific, the serializer shouldn't know the meaning of such meta-data fields. * deletion markers for deleted elements in API responses. We may want to implement this by representing deletions in the DataModel somehow. Additional features we want to support in the future, but should already consider when thinking abotu a solution for the issues above: * Derived values in Snaks (normalized quantities, expanded external IDs, etc). Could be represented in the model in a way similar to TermFallback: ExtendedPropertyValueSnak would extend PropertyValueSnak (and perhaps implement a marker interface, to safeguard against serialization into the database). Note: derived values should not be supported as input to EditEntity, etc. * Filtered representations (terms filtered by language, sitelinks filtered by family or language, etc). Filtering can be done before serialization, but should be marked in the data model and in the serialization, to avoid data loss during round trips. (T73170) * Represent incoming redirects as "secondary ids" in the serialized entity data structure (T98039)