An experiment to create a new, simpler, more featureful, but extensible CSL.
From the beginning, it is designed to add new features even while simplifying the model; notably:
The code here is a typescript
project that:
JSON Schema
files, and
can from there generate different language code via
quicktype.A first draft of the model is almost complete, while the second currently can:
The AST is simply the input style model enhanced with the rendered string for each component of the template. Here's an example bibliography reference, using the files in the examples directory.
[
[ { contributors: "author", procValue: "Doe, Jane" } ],
{
date: "issued",
format: "year",
wrap: "parentheses",
procValue: "2023b"
},
[ { title: "title", procValue: "The Title" } ],
]
Here is VSCode
, with schema-backed validation and auto-completion of a YAML style.
I am using here Deno
rather than Nodejs
.
It includes:
typescript
compiler... and all of it is integrated and very fast.
Deno
also allows compiling a codebase to a single self-contained executable that includes the runtime.
I have a few tasks setup, including to auto-generate an NPM
module.
NPM
module.JSON
schemas.JSON
.Here's a small demo repository that includes a script to run this conversion, and then builds a simple rust binary that can read and write a Style
or InputReference
.
Feel free to experiment with your language of choice and report your experience!
At a high level CSL 1.0 is an XML DSL that sets some context-dependent parameters and provides templates for inline and block formatting of lists (citations and bibliographies respectively).
But it has two limitations.
First, the template model is pretty complex, and so difficult for users and developers alike.
Second, it has no method for extension, so any change in behavior requires changes in the XML model, and often, by extension, the styles, and the input schema. Given the diversity of software implementations and thousands of styles, and the fact that much of the labor to maintain all this comes from time-strapped individuals, the lack of extensibility enforces a large degree of inertia that we need to address.
This is one idea on how we might do that, then.
It's a placeholder to call it something, without suggesting any particular future.
typescript
?JSON schema
(for other language targets, see quicktype).JSON schema
, even in YAML
.JS
world, and JS
widely supported more generally.EDTF
JavaScript libraries for date validation and formatting.JSON
/YAML
and JSON Schema
? What happened to XML
?JSON
(and YAML
) is much more broadly-supported today.I've opened the discussion forum for general discussion, feedback, and questions.
Pull requests are welcome. If you're interested in contributing, see the issue tracker for details, particularly #7, and the milestones.
I'll likely add more guidelines later, but you can review the commit history to see the general strategy on commit messages, and I have the CI setup for pull-requests that should flag linting or formatting issues, along with deno tasks to flag and clean those up locally.