The issue of interchanging a set of files among different systems can be partially addressed by an interchange packaging scheme that includes an interchange catalog that associates external identifiers with the various files in the interchange package. This resolution, which assumes the catalog format defined above, describes such a scheme.
This resolution does not support the use of explicitly specified system identifiers; that is, an external entity's declaration may specify a public identifier or it may use the SYSTEM keyword with no system identifier (in which case the entity's name will be used to do a catalog lookup for a matching catalog entry indicated by the ENTITY keyword). This resolution assumes a transmission medium that allows for the interchange of names for the various files in the interchange package.
The actual transmission medium and details of writing and reading the interchange package are irrelevant. This resolution assumes that there exists a single location (e.g., directory) on the receiving system that already contains the set of interchanged files. (The generation of such an interchange package by the sending system is not explicitly discussed, but it is assumed that this discussion about receiving and interpreting an interchange package will make clear what is necessary to do on the sending system.) In this resolution, the phrase "interchange package" refers to this set of files in this location and "interchange directory" refers to this location.
An interchange package must have at least one file that shall function as the interchange package's catalog. This catalog entry file must have a mapping for all files in the interchange package. That is, for each file in the interchange package (other than this catalog file), there must be a catalog entry whose s.o.i. identifies the file.
To determine what file in the interchange package shall be used as the catalog, an application shall use the following algorithm (or functional equivalent):
If the document entity's s.o.i. is somehow known to the application, the application should first look for a storage object whose s.o.i. is docname.soc where "docname" is the "base name" of the document entity's s.o.i. An s.o.i.'s base name is determined as follows:
within the s.o.i., locate the last (rightmost) character that is either "/" or "\" if any;
within the string to the right of this character (or within the entire s.o.i. if there are no occurrences of either the "/" or "\" character), locate the last (rightmost) "." character (called the dot, period, or full stop character) if any;
the string consisting of all characters in the s.o.i. up to but not including this "." character (or the entire s.o.i. if the previous step found no "." character) shall be the s.o.i.'s base name.
(The base name determination algorithm is optimized for URLs and certain common file naming schemes; however, on all operating systems, this algorithm may fail to be useful unless appropriate naming conventions are followed.)
If the docname.soc s.o.i. names a relative (as opposed to absolute) location, it shall be resolved into an absolute location using the same process used to resolve the document entity's relative s.o.i. into an absolute one. (This resolution does not specify how the application may know the document entity's file name prior to reading the catalog. It may be given to the application via a command line option or a via a user dialog. Note, of course, that the DOCUMENT entry in the catalog cannot be used to determine the document entity's file name for the purposes of determining the catalog's file name.)
Then, look for a file whose name is catalog.
Finally, look for a file whose name is catalog.soc.
Ordinarily, the catalog should include a single entry of the DOCUMENT type whose s.o.i. identifies the file in the interchange package that is the document entity in which parsing begins, if any such entity exists in this interchange package. (Some interchange packages may not include such an entity, for example, if the interchanged files are a set of entity declaration files.) Although it does not prohibit such interchange, this resolution does not make explicit allowance for including multiple documents in a single interchange. To ensure maximum portability, each interchange package should consist of at most one document. (Since this resolution does not address details of actual transmissions, it does not prohibit multiple interchange packages within a single transmission.)
Provided that the interchange package's catalog has an unambiguous entry for each file named in the interchange package, an interchange package is valid even if the receiver must modify the s.o.i.s in his/her copy of the catalog so that they are valid on the receiving system. However, when the sending and receiving systems have compatible naming schemes, files in the destination location may be given the same names as they had on the sending system. This possibility is more likely because relative paths in s.o.i.s are relative to the catalog file and therefore relative to the top level of the interchange directory. If the receiving system is unknown or incompatible with the sending system, the sender may wish to construct an interchange package with names that are most likely to be valid on the widest variety of systems. (For example, an interchange package with file names of no more than eight alphanumeric characters—and therefore no directory hierarchy—should be maximally portable. However, this resolution does not impose any such restrictions since, in practice, it will often be known what the receiving system can handle, and it will be preferable to take advantage of its capabilities.)