I started working on the teidata.version = teidata.version.unicode | teidata.version.semver | teidata.version.calver | teidata.whatever system today. (In a branch I have not committed, let alone pushed.) Less than halfway through the process I ran into a (moderately embarrassing) problem. It turns out calVerhttps://calver.org/ is not a calendar-based version numbering system as we had assumed during our recent discussions. It is rather a cheerleading document in favor of calendar-based versioning in general, with both a breakdown of the potential components such a version number might use, and a list of specific projects that use a calendar-based version numbering system (along with the pattern of aforementioned components that project uses). My first reaction is I have no idea what we should do about this. My second reaction is I can easily scope out a range of options, as follows. 1. Do nothing with calVer — drop it from the list of TEI datatypes-to-be. 2. Go whole-hog: For every system described by calVer, create a TEI datatype that validates it. E.g., the datatype for the Ubuntu system would be defined with something like <dataRef name="token" restriction="([4-9]|[1-9][0-9]|[1-9][0-9][0-9])\.(0[[0-9]|1[0-2])(\.[0-9]+)?"/> Datatypes could be named flatly, e.g. teidata.version.ubuntu, or could be named hierarchicly, e.g. teidata.version.calendar.ubuntu. 3. Something in between. (E.g., calVer divides systems into case studies, notables, and others; maybe do #2 but only for the case study ones.) I really don’t like #1, because, in general, this is a great way to do version numbering. I encourage everyone to scan the major portions of the calVer document, if not read the whole thing.