TAN files have been designed to be shared and linked, just like any network of files. Most often, TAN files will be created and distributed as collections, not single files.
One way to distribute a collection is to make it available as a repository via Git or some other version control software (VCS). This approach has many advantages. You can collaborate with a wide variety of people, and preserve an editorial history that allows you to branch or backtrack, if needed. VCS features and tools are extremely fast and useful.
Collections may also be distributed through shared syncing services (e.g., Drive,
Box, or Dropbox), or put on a Web server. In the latter case, it may be difficult for
users to browse or download your collection of TAN files wholesale. In that case, you
may wish to expose the collection as a compressed ZIP archive. This saves on your
server's 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 target of <master-location>
. Unpacking a compressed file requires
writing to the disk, which is treated as a security risk during validation. Such
zipped archives are good ways to distribute a collection, but they should not be used
as a primary repository or a master location.
When you share a TAN file, make sure to include its dependencies, the files
pointed to by <vocabulary>
or <inclusion>
. If you are simply trying to email a single file,
you could send a resolved version, which does not require any other dependencies (see
the section called “Resolution”).