TAN files have been designed to be shared. Although individual TAN files are likely to be valuable on their own, even when removed from their context (e.g., via an email attachment), they may be critically crippled without their dependencies. As a result, TAN files are most likely to be distributed or published in groups, as collections.
One way to distribute a collection is by making it available as a repository via Git or some other version control software (VCS). This approach has many advantages. The files become available to whomever wants them, and the editorial history is preserved. VCS features and tools are extremely fast and useful, and they allow users to modify TAN collections without impacting the original source.
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 browse a collection. 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, nor is it appropriate as a <master-location>
. Unpacking
a compressed file requires writing to the disk, which is treated as a security risk
during validation, and so is disallowed. Such zipped archives are good ways to
distribute a collection, but they should not be treated as a primary
repository.