Hi Syd,
Just following up from the council meeting last week: my vote is to (mostly) do option 3 — e.g. create datatypes for versioning systems that use CalVer and might be useful in the Guidelines. I think option 2 is a bit impossible since, as you describe, CalVer is an idea ("have some sort of date in your version") and not a specification. This is also why I think that we shouldn't name these hierarchically (since they aren't really hierarchical—they are just all loosely using the principle of calendar versioning).
From the CalVer list, I'd argue for Ubuntu and LibreOffice (which is an interesting example, since it appears to have used a Semantic-ish style version system until January 2024https://en.wikipedia.org/wiki/LibreOffice#Versions) as datatypes, since they could reasonably be used in a TEI document. In fact, I think once we do this, we should investigate whether LibreOffice documents surface version information that can be used by read and recorded by odttotei.xsl (if we don't already).
Best,
Joey
⎯
Joey Takeda
Developer, Digital Humanities Innovation Lab
Simon Fraser University Library
takeda@sfu.ca
Unceded territory of the səl̓ilw̓ətaʔɬ (Tsleil-Waututh), kʷikʷəƛ̓əm (Kwikwetlem), Sḵwx̱wú7mesh Úxwumixw (Squamish), and xʷməθkʷəy̓əm (Musqueam) Nations
On May 21, 2024, at 2:44 PM, Bauman, Syd via Tei-council wrote:
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.
_______________________________________________
Tei-council mailing list -- tei-council@lists.tei-c.orgmailto:tei-council@lists.tei-c.org
To unsubscribe send an email to tei-council-leave@lists.tei-c.orgmailto:tei-council-leave@lists.tei-c.org
