TEIC
Are there other formats that the Stylesheets should convert to/from?
We have a lot of formats that should be deprecated -- e.g. Cocoa. But, on the flip side, there are a number of formats that we don't support that are very popular and related to the TEI--for instance, Page XML, ALTO, IIIF, geojson, hocr. These conversions exist, but are not part of the standard Stylesheets (and thus, arguably, a bit less findable for the TEI community).
So this is a bit of a broader question, but: Should we be expanding the Stylesheets? Or, if not, should we be thinking of ways to promote/link out to these tools?
This is an interesting suggestion. What would be the rationale for creating a new tei-to-x conversion? Evidence that a widely used piece of software doesn't natively support TEI input, but does support format x, presumably. And likewise, to justify writing an x-to-tei convertor you'd need to be sure that there's software which produces x that would be so much cooler it output TEI. I wonder how you'd determine which non-TEI formats are used in either scenario -- and I'd be surprised if most of them are not already covered by the existing portfolio of convertors. So this would be mostly an outreach/publicity effort, reasserting the TEI as "text encoding for interchange". And by the way, what's your problem with Cocoa format? I doubt if anyone is still producing it but I'll bet there's still plenty of it kicking around. And even if not, it's an important and influential milestone in the evolution of our field. Look at all the other bits of software which support it. What exacgtly does "deprecate" mean in this context - no-one is proposing to change it, but why should the TEI not continue to make available a suggested conversion for it? (Someone will have to update the wikipedia entry for cocoa if they don't)
The problem is that by adding new formats, we're undertaking a maintenance burden, especially if those formats (along with the TEI) change over time. Sebastian's expectation that these formats would be adopted and maintained by the community has not been borne out; if a Council member with a familiarity with a new format were to write the to- and from- conversions and then cycle off Council and stop maintaining them, any issues then fall to the rest of Council who may not know or care about the format.
It rather depends on what it means to "support" a given transformation stylesheet. I don't think any of the current set actually has a systematic review/test procedure when a new release of TEI or the Stylesheet library happens and I don't recall having seen any outcries as a consequence. (Obviously the ones used internally for ODD processing etc are not in the same league). But it would certainly be useful to distinguish which convertors are now purely of historical interest. It would also be really nice if Council took on formal responsibility (i.e. bug fixes) for some of the most widely used such as to/from docx (itself a moving target of course)
Not much support is needed on COCOA's end, presumably, apart from a piece of the test suite. And if the TEI infrastructure in time remains the only way to get text out of COCOA in a systematic, tool-friendly fashion (rather than by ad-hoc scripting) then all the more power to the TEI.
I don't think Council should ever make a formal commitment to support conversion to or from a format that isn't at the core of the mission of the TEI; there's too much to do just maintaining the standard and ODD processing. If anyone has a particular interest in a specific format, then they are free to implement it and raise a pull request to add it. The docx conversions are a good case in point; Sebastian liked docx and put a lot of work into the conversions, but I don't believe anyone currently on Council could be called an expert on docx, or an enthusiast for it. Lots of issues are raised related to the docx conversion, which puts us in a difficult position.
I doubt that anyone has used the COCOA conversion in a decade; anyone who had COCOA files around would surely have converted them to something else long ago. But there's no harm in leaving it there as long as nobody needs to maintain it, or an external maintainer will step up.