Be liberal in what you accept from others

[dstillman]

citeproc-rs is no longer usable with some bundled styles now that they've been updated to include CSL 1.0.2 terms:

zotero(1)(+0000001): CslStyleError: invalid style: bytes 8506..8518 [Error] Unknown attribute value for `term`: "video" ()

    CiteprocRsError@resource://zotero/citeproc_rs_wasm_include.js:3:9
    CslStyleError@resource://zotero/citeproc_rs_wasm_include.js:16:9
    init/imports.wbg.__wbg_new_bb3cad8cb87701ce@resource://zotero/citeproc_rs_wasm.js:782:17
    wasm::errors::<impl core::convert::From<wasm::errors::Error> for wasm_bindgen::JsValue>::from::h2d9796b0a61638b1@resource://zotero/citeproc_rs_wasm.js line 746 > WebAssembly.instan

#144 would address this specific issue, of course, but the same would apply for invalid user-edited styles, which have always triggered a non-fatal warning: "%S" is not a valid CSL 1.0.2 style file, and may not work properly with Zotero.\n\nAre you sure you want to continue?.

I'm not sure what exactly citeproc-js does in these situations — it supports CSL 1.0.2 terms already — but I believe it does not produce fatal errors. Ultimately, for most end users, imprecise output — or simply output that doesn't reflect the latest CSL changes — is going to be strongly preferable to hard failures, since they can always make manual final edits as necessary. And for word processor plugin usage, some temporarily incorrect output that was fixed before final output wouldn't matter at all, whereas a hard failure very much would.

From a development/deployment perspective, some leniency also makes things like CSL schema changes vastly less fraught. As is, code and style distribution would need to be precisely aligned — potentially an impossible goal, given various ways people can get styles, how styles auto-update, how new code is beta tested, etc. — to avoid completely breaking people's workflows.