Sharing TAN files

TAN files have been designed to be shared. Although individual TAN files are likely to be valuable on their own, absent any context (e.g., if one is sent as an email attachment), they also link to other files, and may be critically crippled without their dependencies. As a result, TAN files are most likely to be distributed or published as collections.

One way to distribute a collection is by making it available as a repository on Git or through some other version control software (VCS). There are, at present, few drawbacks to this approach. The files become available to whomever wants them, and the editorial history is preserved, so that a change one person makes to TAN files used by another need not necessarily be written in stone. On the other hand, Git and other VCS packages make updates extremely fast and convenient.

Collections may also be distributed through shared syncing services (e.g., Drive, Box, or Dropbox). Or put on a server. In the latter case, it may be difficult for users to navigate and see where an entire collection is house. In that case, you may wish to expose the collection as a compressed ZIP archive. This saves on your own bandwidth, and it still exposes the files for XML processing. But a ZIP archive is not suitable for linking from one TAN file to another. Engines that check Schematron validation will invariably need, in unpacking the compressed file, to write to the disk, which is a security risk, and so is disallowed. Such zipped archives are excellent ways to distribute collections, but they cannot serve as a primary repository.