Have I thought about how easy it is to implement? For me? Pretty easy.
It would need some other things to be successful.
- It would need backpressure. Using a schema addition instead of the ‘standard library’ of variables reduces the portability of people’s references between styles. So its use should be generally discouraged where existing stuff would do the trick. I don’t imagine this stance will be difficult to take for the CSL maintainers, given how easily saying no can be justified!
- It would also need documentation. Not of how to use the feature, but when to use a custom-schemas variable and what it will do, whether it’s deprecated. Essentially you need javadoc/rustdoc-style documentation for each key. Ideally this would be compulsory and pull requests to the styles repo would enforce it. With a
deprecated = "for X reason"tag. That GUIs will actually warn you about. That’s the third thing: - This is a feature for end-users, not style authors. Without GUI support and attention to detail over the experience, the validation capabilities are worthless. “STYLE HAD AN ERROR CODE -4188” is much worse than what we have now. That’s where the actual implementation burden is: with Zotero, that means error codes and translations for UI elements. Building a engine->user warning path would be useful in other ways, however. I would like to be able to bubble up things like “invalid raw date string” and “could not disambiguate”, not only do a best-effort rendering.
- Because it connects end-users to style authors more directly, this might have implications for how people seek support. Are people still going to think to post on the Zotero forums and file GitHub issues if they see docs/text written by individuals? I’m a programmer so I have “find where the source code is hosted, read it, maybe fix it yourself and don’t assume the original author actually has time to deal with your problem individually” drilled into me, not sure if everyone else does.