I’m having a hard time following the updates for 1.0.2, but at least from https://github.com/citation-style-language/schema/pull/227 it looks like we don’t have a variable for citekeys (there’s citation label, but as per the specs that’s for thinks like KaSm99 that’s part of printed citations).
Am I right about this? If so, should we add this? Seems like it’d really help with transfer between Word/LibreOffice and citekey based formats like pandoc markdown and LaTeX.
Yeah citation-label is not the same thing as citekey. But there is id already in csl-data.json. That should be the same as citekey, right? If so, isn’t that question more relevant to Zotero and other end reference managers?
If not, what would the intended purpose of citekey be next to id?
Or is this about making citekey available in styles?
Isn’t the id controlled by the application? citekey on the other hand should be under user control. Looking at a citekey in a mansucript should intuitively reveal to the author what is cited, while a numeric id, generated by the application hardly would.
That depends on the application. In a plain text context, id is used as a citekey. Zotero is different of course.
Of course, when I write a bibtex file or manually a csl json file (is that regularly done besides of testers?), I wouldn’t invent an id besides the citekey. But whenever an application collects the data in a database, it will most probably have to assign a id that is safe from human manipulation. Therefore a separate citekey variable that could be exposed to the user is a good idea IMO.
But isn’t that just a question of which fields e.g. Zotero has. I’m all in favour of a citekey field in Zotero that could be used to populate csl id on export to csl json, yaml or bibtex. But I don’t see why we should need a variable in CSL for that. (Perhaps there are use cases, but I am not convinced this is one.)
By the way: this us just how the citekey field by BBT is currently handled.
This. Applications should set the id to the citekey if users want this feature.
Right?
ID = citekey; they’re the same thing.
We could make this explicit in the spec though?
Agreed. id is the equivalent to citekey in CSL-JSON. Considering that Zotero and Mendeley don’t use the id field at all in their Word processor plugins, they should probably always put a citekey there.
Well, seeing that id is the only required field from the item object according to the schema, I got the impression that there was more importance to it.
So, the id is used only for identifying the same object within the word document not for identifying it in the communication with the source application?
Practically speaking, it’s only a local token to link citation and source.
Which is what a citekey is.
Aside: early on, I went out of my way to avoid borrowing from bibtex 
I don’t have a fundamental objection to using id for this, but I think you’re making this sound too simple:
Before turning an auto-generated, non-displayed variable into something that’s displayable and user-configurable (that can be duplicate in a document, e.g. if multiple people edit a document), it’d be worth checking with implementations on how they use it and if that’d cause problems.
I don’t think Zotero does much with the id – they use the uri they display outside of the schema JSON for linking, but Mendeley might, for example, and we don’t have much insight on other tools like paperpile and Readcube/Papers on this.
And even where the application doesn’t use it much, if this is going to be in 1.0.2 it may still require more changes to word processor integration to deal with old ids in documents, e.g., than would be desirable for a minor update.
Just to clarify: I, at least, was not talking about changing the ways how Zotero interacts with word processors. All I was saying is this: If Zotero added a citekey field, this can just be mapped to CSL id at export time. But that should not affect interaction with word processors at all.
Admittedly, I hadn’t thought about that.
I see three options:
id was designed, from the beginning, with this case in mind)citekey), that may-or-may-not be the same as the id (what you suggested at top)There are problems with all three, but I think we should do 2 or 3, and still lean towards 2.
I agree we should have feedback, but the only project developers who’ve been around here and active recently is @Dan_Stillman, who I am certain has thought about this issue, given that’s come up in the zotero forums since the beginning.
On implementers: we really need to get them added to a PR review team, and a commitment to actually provide feedback, but I don’t even know at this point who we contact.
Right, I don’t think it should have to change, but since id is used in the current data model in the word processor integration, I’m wondering if using it for citekey would require a change.
Isn’t it already used for citekey, e.g. by pandoc.
But that’s just because that’s how pandoc understands internal ids. Using ids for citekeys means we’re changing how that variable is expected to work - it can now be printed, it can be changed by a user, it can be changed in an existing document, etc. There’s a fair chance that will cause problems for applications that in some way have relied on the previous behavior.
It’s possible that’s not the case, in which case I think Bruce’s 2) is definitely the right choice, but if it will require significant adjustments by implementers, that’d strengthen the case for 3)
How does citation-label fit?
I think citation-label has a different purpose.
That said, I still don’t really understand what the intended purpose of a citekey variable would be that id can not cover. Can someone give an example?
citation-label is entirely separate, at least as currently described:
citation-label
label identifying the item in in-text citations of label styles (e.g. “Ferr78”). May be assigned by the CSL processor based on item metadata.
So if you have a trigraph style (like American Mathematical Society or the DIN one we currently have available), you’d need both that and a citekey