Upcoming CSL meetup context

CSL Development
8

Meeting notes (still open for comments)

(I tried to quickly add them here, but formatting got screwed up)

High-level summary

Great discussion, but we didn’t really resolve the key questions. Hopefully we can in the coming months.

Any further thoughts on how to do that, please post them below.

My further thoughts and ideas

YAML tests?

One small thing I was wondering: should we switch to YAML (or TOML) for the test suite, per @cormacrelf’s example?

Define two (or more) change types, and match them with GitHub review teams

One bigger question, that is about process and labor:

If we do decide we want to release a bigger change, and so have a plan to evolve CSL going forward, perhaps we could have github teams to review different kinds of changes?

For example, processor developers could be on a “Processor reviewers” team, and we could have a separate team for variables/type/term additions and such (adding strings).

Issue triage could then classify and auto-assign reviewers.

And if we don’t want to be bothered, we should just say so and declare CSL effectively frozen, aside from minor changes.

But per @Sebastian_Karcher’s point during the meeting, I’d prefer not to give up the goal of being able to evolve CSL, despite all of the inertia.

Is a schema with more modular features possible?

On that point, I guess the even bigger question is if it’s technically possible to do what some were musing about: having modular features that processors could support, or ignore without consequence for backward compatibility.

I haven’t ever really looked into this idea, but I’m skeptical it is possible.

But that would solve a lot of problems if it was.

Certainly some of what we added to “1.1” could be ignored by a 1.0 processor. But we’d basically need rules for that; e.g. “Processors shall ignore unknown nodes.” And with that, it may constrain some of what we added.

But I’m not sure; maybe we should look into that more?

Off the top of my head, for example:

  • cs:intext would work, while this alternative would not
  • split titles almost surely would not
  • EDTF dates: not sure
  • related-items: no