The data schema is versioned; 1.0 has a different id than 1.1 will.
I’m not sure if we also need to add a top level version property for this as well, but if the data format is versioned, there’s no problem; is there?
A CSL JSON file currently has no indication of its version, it just gives item data. I expect there will be a very long delay all sources serve data with a new version, and there are existing data files (e.g., in archived manuscripts or with embedded data in Word documents) that won’t ever be updated. It’s not clear to me how we would expect a processor to handle these if we drop support for old structures or variables. At a minimum, processors will need instructions as to what they should do when they encounter deprecated or removed structures or variables.
1 Like
As I said, though, we an add one.
{
"version": "1.1",
"references": [ ]
}
Yeah, you’re probably right. I was actually initially thinking of that; a python script that does some pre-processing, and then runs the XSLT.
Want to submit a PR ;-)?
But for all of the existing un-versioned data—it’s assumed that it is 1.0.2 or earlier?
Yes, exactly.
That would also give us a place to put other metadata.
One wrinkle to consider is Dan Stillman’s comment comparing RIS and RDF—a strength of RIS is that each item is self-contained and it’s easy to copy and transfer a single item from a file.
I don’t think a single meta field at the top of a file is necessarily a problem, but it’s something to consider and weigh against, e.g., putting the meta in each individual item.
We wouldn’t want to allow a file to mix different versions though; that’d be a nightmare.
Copying-and-pasting already won’t work across versions, given the change in the date model.
But sure; those are the details we should consider.
Sorry, maybe I am missing something, but I think there are some potential problems when deleting deprecated variables:
We can control the official CSL styles and make sure that they will update (e.g. like you indicated with a XSLT script) shortly after the schema is updated. But how can we then make sure that old CSL JSON data 1.0 can be displayed with a new CSL style 1.1?
The old data file may for example still have an event-variable but the new style file does then only handle event-title-variable. Then, it is up to the processor (not in our control) whether there is any mapping, or whether any alias mechanism is respected.
Or do I have some error in the argumentation here?
I would expect a CSL processor that supports both 1.0 and 1.1 to be able to read the 1.0 data and apply it to a 1.1 style (so it sees original-title but converts that internally to ['original']['title']). Why would that be a prolem?
A 1.1 processor (say something new developed next year) might say it won’t accept 1.0 data or styles.
What about a processor that only accepts 1.0 data and styles? It will not work anymore correctly, when the official styles are switched to 1.2, right? (Or will all 9.500 styles coexist in version 1.0 and 1.2?)
I imagine we could tag the repo so that applications that rely on old styles can still use the latest versions?
They will have different branches in the repo for different style versions. So they won’t be separate files, but separate branch versions.
They will have different branches in the repo for different style versions. So they won’t be separate files, but separate branch versions.
Another other option is separate sub-directories per version?