zotero / citeproc-rs

CSL processor in Rust.

Home Page:https://cormacrelf.github.io/citeproc-wasm-demo/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Error: unknown field `shortTitle`, expected `any CSL variable`

adomasven opened this issue · comments

Zotero debug log
zotero(5)(+0000000): CiteprocRs: insertReference {"id":"HtwJTceP/5JtRiY3k","type":"article-journal","title":"Visual spatial constancy and modularity: Does intention penetrate vision?","container-title":"Philosophical Studies: An International Journal for Philosophy in the Analytic Tradition","page":"647-669","volume":"165","issue":"2","source":"JSTOR","abstract":"Is vision informationally encapsulated from cognition or is it cognitively penetrated? I shall argue that intentions penetrate vision in the experience of visual spatial constancy: the world appears to be spatially stable despite our frequent eye movements. I explicate the nature of this experience and critically examine and extend current neurobiological accounts of spatial constancy, emphasizing the central role of motor signals in computing such constancy. I then provide a stringent condition for failure of informational encapsulation that emphasizes a computational condition for cognitive penetration: cognition must serve as an informational resource for visual computation. This requires proposals regarding semantic information transfer, a crucial issue in any model of informational encapsulation. I then argue that intention provides an informational resource for computation of visual spatial constancy. Hence, intention penetrates vision.","ISSN":"0031-8116","shortTitle":"Visual spatial constancy and modularity","author":[{"family":"Wu","given":"Wayne"}],"issued":{"date-parts":[["2013"]]}}

zotero(3)(+0000002): Error: unknown field `shortTitle`, expected `any CSL variable` at line 1 column 1306
    init/imports.wbg.__wbg_new_1d56e97b8de3067f@resource://zotero/loader.jsm -> resource://zotero/citeproc_rs_wasm.js:560:19
    js_sys::Error::new::h2b65a8ba67ca4d24@resource://zotero/loader.jsm -> resource://zotero/citeproc_rs_wasm.js:3931381:1
    wasm::Driver::insert_reference::hbe371febbe99ccd6@resource://zotero/loader.jsm -> resource://zotero/citeproc_rs_wasm.js:3353019:1
    driver_insertReference@resource://zotero/loader.jsm -> resource://zotero/citeproc_rs_wasm.js:3850562:1
    insertReference@resource://zotero/loader.jsm -> resource://zotero/citeproc_rs_wasm.js:250:9
    _insertCitationReferences@chrome://zotero/content/xpcom/citeproc-rs-to-citeproc-js.js:94:9
    insertCluster@chrome://zotero/content/xpcom/citeproc-rs-to-citeproc-js.js:141:23
    Zotero.Integration.Session.prototype._updateCitationsCiteprocRs@chrome://zotero/content/xpcom/integration.js:1882:7
    Zotero.Integration.Session.prototype._updateCitations@chrome://zotero/content/xpcom/integration.js:1817:12
    Zotero.Integration.Fields.prototype.updateDocument<@chrome://zotero/content/xpcom/integration.js:992:9
    tryCatcher@resource://zotero/loader.jsm -> resource://zotero/bluebird/util.js:16:16
    module.exports/PromiseSpawn.prototype._promiseFulfilled@resource://zotero/loader.jsm -> resource://zotero/bluebird/generators.js:97:18
From previous event:
    captureStackTrace@resource://zotero/loader.jsm -> resource://zotero/bluebird/debuggability.js:915:23
    CapturedTrace@resource://zotero/loader.jsm -> resource://zotero/bluebird/debuggability.js:807:5
    longStackTracesCaptureStackTrace@resource://zotero/loader.jsm -> resource://zotero/bluebird/debuggability.js:482:19
    module.exports/Promise.prototype._then@resource://zotero/loader.jsm -> resource://zotero/bluebird/promise.js:261:9
    module.exports/Promise.prototype._passThrough@resource://zotero/loader.jsm -> resource://zotero/bluebird/finally.js:94:12
    module.exports/Promise.prototype.finally@resource://zotero/loader.jsm -> resource://zotero/bluebird/finally.js:103:12
    PromiseSpawn@resource://zotero/loader.jsm -> resource://zotero/bluebird/generators.js:36:25
    module.exports/Promise.coroutine/<@resource://zotero/loader.jsm -> resource://zotero/bluebird/generators.js:197:21
    Zotero.Integration.Interface.prototype.refresh@chrome://zotero/content/xpcom/integration.js:699:9

I received an

Error: unknown field `shortTitle`, expected `any CSL variable`

when calling insertReference()

Looks like it is a real CSL variable, is it meant to be the same as title-short?

Ok, probably best to fix this on Zotero's end then. For the record I ran into this by testing on a document generated about 2 years ago and using its embedded metadata, which is why it got triggered.

I'll map it to title-short as well since it's in the schema. 2-year-old documents should still go.

Would you also prefer this to be a soft warning not a hard error? I think probably yes, if only to smooth over CSL point releases.

We'll have it serve title-short to citeproc-rs in all instances, so it doesn't matter to us, but for any other consumers that might be switching it's probably best to keep it a warning.

I mean in general, for any unrecognised CSL variable.

Let's keep it a warning. Also, how does citeproc-rs report warnings? Is there any debug output that can be enabled for it?

It does log some warnings and errors at the moment, but the wasm package is configured to try to write it to window.console.warn/.error/etc which might just completely disappear in Zotero (or fail!). Then again it might just not be encountering any warnings, there aren't many in the codebase at this point. One way to trigger a warning and try it out is to add an author with a silly given name like Givenname, et al., which is not something I wrote a regexy parser to handle but I get the impression citeproc-js might have, so at the moment I just log it as a warning. You could also add a typo to a locale file that's being loaded, as failing to parse one will write an error log, but ultimately not fail the whole thing presently. Let me know how triggering these goes.

Edit: should appear as [WARN][citeproc_io::names] used et-al as a suffix in name, not handled with citeproc-js-style hacks

If that's not doing anything, it would be easy to accept a JS object that has all the normal window.console API but in single-string-argument form, and default to using the real window.console. The other part I have thought about before is essentially allowing the consumer to pass some configuration through to https://lib.rs/log, which can set a log level per rust module, so you can e.g. turn on disambiguation logs (citeproc_proc::db=debug,citeproc_proc::disamb=debug). I think I'll do that, probably with that syntax as log can already handle it.