January, 2024 update

[bdarcus]

As I expected, I haven't had much time to work on this in the past few months.

I do think, however, the code is complete enough to demonstrate, and I think validate, the basic idea.

Take a look at the YAML example files; they're not complete, but show the basic idea. Think about how style files, in particular (for example for Chicago 17), might be rendered in a GUI

The idea

A simpler and easier to develop and extend CSL

The basic idea is the exact opposite of CSL 1.0. Rather than develop input schemas independently of code, here the schemas are generated from reference code. Necessarily, then, going forward, the two would be designed in tandem.

So a new feature, for example, would not be added without simultaneously submitting the documented code that implements it, along with test coverage and examples.

We might even find a good way to generate documentation from the code, so updates to it all (crates, docs, schemas) would happen by github workflows.

Rust

The idea in writing it in Rust is also to make it suitable for use in different contexts, so that one could write implementations in different languages if one prefers, one could also just write some glue code to interact with the reference processor.

That would then make development easier, and resolve some of the questions we have about evolving the language into the future. The fact that the template part of the language is also much simpler would make it easier on independent implementations.

Finally, the rigorous type system seems better suited to a reference implementation, and in turn enables the above.

Code

I did merge very basic citation support recently and update the milestones to better reflect where things stand, which is to say:

• there's a reasonable bit of work to do on the hairier details of citations and disambiguation
• I've pushed the milestone deadline for 0.3 to the Summer, and removed deadlines from the subsequent ones

If I continue to do all of this work myself, it may take awhile ;-)

I'm still learning Rust, and so I have a feeling there are places that are less-than-optimal.

But I've tried to keep this code as conceptually clean as possible, and have ensured cargo clippy runs warning free.

After running cargo build from the root repo directory:

• run ❯ target/debug/csln-schemas to generate the JSON schemas for the models; they should closely match the internal model, and csln will panic, for example, if the input files aren't valid against the schemas. To be clear: the input schemas are completely generated from the Rust data models; there is no additional code to develop or maintain for this.
• play with the csln binary for processing to see the current output (it's JSON-only now, but I will later implement Pluggable Renderer design #105).

I've not really worried about performance so far, but this is what the csln release build shows on my older Thnkpad X1 carbon laptop, running examples files:

> time target/release/csln -s processor/examples/style.csl.yaml -b processor/examples/ex1.bib.yaml -l processor/locales/locale-en.yaml -c processor/examples/citation.yaml

...
________________________________________________________
Executed in   37.67 millis    fish           external
   usr time  191.45 millis    0.00 micros  191.45 millis
   sys time   21.75 millis  608.00 micros   21.14 millis

So it's deserializing four smaller YAML files, processing them, and then serializing that result into JSON output:

        {
          "templateComponent": {
            "date": "issued",
            "form": "year",
            "rendering": null
          },
          "values": {
            "value": "2020",
            "prefix": null,
            "suffix": ""
          }
        }

Aside: the idea of the plugin output system will be that it takes that internal result, and transforms it into the final output.