Thanks @Sebastian_Karcher! I edited out a couple of details you added to your post.
I’m worried about the general idea of individual extensibility.
The extensibility is more on the development side, to make it easier to evolve core CSL.
It would be like allowing foreign nodes in certain places in CSL 1.0, and so letting developers and users experiment with alternatives without breaking compatibility.
I guess my biggest high-level concern is that I think technical debt is called debt for a reason: switching costs to a completely new system are significant.
There’s no denying this, and the issues you raise are the ones that concern me.
I’m also concerned about how much responsibility under the status quo is placed in the hands of busy people who are donating their time. I don’t think that’s likely sustainable.
There are also socio-technical costs: e.g. people like Patrick and me, who have looked at thousands of styles are very proficient with the existing syntax and can read and modify it at high speed. Even with a technically improved system, it would almost certainly take a good amount of time to get to a similar level of fluency.
Part of my idea here, which could actually be implemented in a tweak of 1.0 to allow standalone macro files, is if maintainers could spend more time on curated macros files, styles themselves are likely to become potentially much simpler, and so easier to create and maintain.
But I also think we need tools to automate a lot more of this, including that average users can use, so they are not dependent on the knowledge of a small circle of experts.
BTW, I think doing server side validation of these files using GitHub Actions would be trivial. I may even integrate it into the repo just to show/test.
Even with the very limited infrastructure changes required for the CSL 1.0.1–> 1.0.2 switches, it turned out to be a fair amount of work to make the switch even after the schema and specs (the main chunk of the work) were done. CSL has become vital scientific infrastructure. Who will be responsible for planning and running a much more complex transition? Can that even be done without someone working on it full time?
These are absolutely the right questions, and the very fact that it required much work at all signals a problem in my view.
But FWIW, I think it would likely mean new repos, and rethinking how we have done things for the past decade and a half.
In my experiment, the schemas and developer docs are generated from the commented code, and so can be automated by CI.
And if we can improve tools per my point above for users too, maybe that lessons the burdens on central repository maintenance, or even scales back its purpose?
On the other side of the equation, at least going by the quite limited uptake of the CSL 1.0.2 update over the last ~17 months, I think the case for the importance of CSL schema updates is at least not obviously strong (even though there are certainly things, esp. multilingual, I’d love to support better).
That’s not really surprising, nor does it show there’s no desire for change. The changes in 1.0.2 were fairly trivial. Even then, they broke
(Though, as an aside, I don’t believe the changes were particularly disruptive to other processors, so suspect there’s something unique about
OTOH, multilingual, proper support for APA integral/narrative citations, independent formatting of titles and subtitles, richer date and time support, etc. are bigger deal features, which we can’t support without changing the XML model (new elements and attributes), which means parsers break, style updating will be a nightmare, etc.
So we go back to our questions from last Summer:
Do we have a plan to evolve CSL, that considers all of these socio-technical issues, or do we just freeze the schemas?
Not answering the questions, in my view, is freezing by default.
grouping: I’m not sure grouping and disambiguation are as tightly related as your comments imply. I don’t see, e.g., why a style would need to group by author if it disambiguates by author (even though many do).
I’ve gone back-and-forth on this one.
I still think it’s related to grouping, and I can explain why in the author group case.
I’m struggling a little with the year one though.
EDIT: per post below, I figured out in implementation: an author-year group is just that, where you group references based on a combined string:
author:year. The disambiguation rules are then just about whether you add a suffix to the year, and whether you drop the author and year in the output.
PS - I guess in the end, the only way to know if this will work is to finish the proof-of-concept prototype! That’ll take awhile; I’m having to learn a lot to implement the idea, and am a mediocre programmer anyway.