| Tgr added a comment. |
@Halfak the questions is: given that XML readers are somewhat flexible, so a script that was written some time ago and has no knowledge of MCR will still be able to read MCR dumps and see all the fields it expects, and it will quietly ignore non-main slots as unknown fields, what should such a script see at the location where it looks for the sha1 of the revision?
We could put the revision sha1 there, in which case it would be an accurate flag for reverts but would not match the actual sha1 of the "revision content" (as far as such a legacy script understands, "revision content" is just the main slot) when there are additional slots. Also diffs that the script expects to be non-empty (since the sha1 is different) might in fact be empty (since there is no change in the main slot).
Or we could put the main slot sha1 there, in which case it would continue to be the sha1 of the "revision content" (as a legacy script understands it) and the sha1 would change if and only if the "revision content" (main slot) changes. But there could be two successive revisions with the same sha1 (which wasn't possible before) and in general there would be lots and lots of revisions with the same sha1 (when someone edits a slot but not the main revision) so the sha1 would be rather useless for revert detection.
The question is, which is less likely to break or confuse old clients? Now that I wrote this up it seems pretty obvious that the first option (using the combined sha1 in the place of the old sha1) is superior.
Cc: FaFlo, Halfak, vrandezo, Denny, kchapman, tstarling, awight, JAllemandou, hoo, pmiazga, Nemo_bis, brion, Tgr, Aklapper, Fjalapeno, ArielGlenn, daniel, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, Lunewa, QZanden, LawExplorer, JJMC89, Agabi10, D3r1ck01, SBisson, gnosygnu, Wikidata-bugs, aude, GWicke, jayvdb, fbstj, santhosh, Jdforrester-WMF, Mbch331, Rxy, Jay8g, Ltrlg, bd808, Legoktm
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
