My basic plan is to settle on a feature-complete draft style schema, and use that as the metric for 1.0; that we don't tag that until all functionality described in the model:
is implemented
has test coverage
is documented
I've sketched out some rough milestones, but they're very much subject to change, depending on how much progress I make, and who makes what sort of contributions.
I wrote the original CSL 1.0 prototype alongside a book project, which I formatted with it. I hope to do the same here.
This means that while I intend for this to cover various advanced features (extended EDTF dates, localization, etc,), since I don't myself use many of them, they may not be a priority for this initial push.
Needless to say, however, I don't intend to call this ready for "release", whatever we end up calling it, without them. There's not much point in doing this unless I can demonstrate new features as well.
I haven't put any deadlines beyond the Summer, as my time will dwindle at that point.
Contributing
I have a lot of experience with this sort of data modelling (and implemented the very first CSL processor), and that's been my priority: getting it right, and for the input model to tightly-align with the internals.
But I'm an amateur programmer doing this in my free time, and a Rust newbie. So aspects of the internal design are almost certainly less-than-ideal. Feedback and PRs welcome.
I also have not been very involved, for a long time, in developing CSL styles, so could use input from domain experts.
If you're interested in helping, the key design mantra to keep in mind is this:
Keep the template part of the language as simple and elegant as possible, and off-load logic to Style::Config, and the code that implements it.
In that sense, this will be closer to the design of BibLaTeX than to CSL 1.0, and so worth taking a look at its extensive list of options, which I have attached to #64.
This design approach also means there may end up a large gap between the draft model, and whatever "final" one there is. The process will necessarily require the iterative addition and adjustment of config options.
My basic plan is to settle on a feature-complete draft style schema, and use that as the metric for 1.0; that we don't tag that until all functionality described in the model:
I've sketched out some rough milestones, but they're very much subject to change, depending on how much progress I make, and who makes what sort of contributions.
I wrote the original CSL 1.0 prototype alongside a book project, which I formatted with it. I hope to do the same here.
This means that while I intend for this to cover various advanced features (extended EDTF dates, localization, etc,), since I don't myself use many of them, they may not be a priority for this initial push.
Needless to say, however, I don't intend to call this ready for "release", whatever we end up calling it, without them. There's not much point in doing this unless I can demonstrate new features as well.
I haven't put any deadlines beyond the Summer, as my time will dwindle at that point.
Contributing
I have a lot of experience with this sort of data modelling (and implemented the very first CSL processor), and that's been my priority: getting it right, and for the input model to tightly-align with the internals.
But I'm an amateur programmer doing this in my free time, and a Rust newbie. So aspects of the internal design are almost certainly less-than-ideal. Feedback and PRs welcome.
I also have not been very involved, for a long time, in developing CSL styles, so could use input from domain experts.
If you're interested in helping, the key design mantra to keep in mind is this:
In that sense, this will be closer to the design of BibLaTeX than to CSL 1.0, and so worth taking a look at its extensive list of options, which I have attached to #64.
This design approach also means there may end up a large gap between the draft model, and whatever "final" one there is. The process will necessarily require the iterative addition and adjustment of config options.