Hi All -

Some more quick comments are in order here. First, what we are discussing
is a convention, hence revisiting the design is not appropriate (unless
someone wants to propose moving towards a standard; I probably would
not suggest that myself in this case). Second, on the specific issue of
Unix-oriented concepts in the design, this is not necessarily a problem
for something like we have here. Unix Tar for example, exists in Cygwin
(or Winzip etc.) and clearly has some utility even on such a platform.
Things like mode bits, paths, and case sensitivity do not map exactly but
they map adequately; some information is lost when going to a non-Unix
platform, but the extra refinement is useful on reasonably POSIX systems
such as the Unix-derivatives like Linux or Mac. I suspect that if
we produced a rigorous, explicit model for all this, with an explicit
mapping to each platform, we would not do much better and would only
complicate things. If something like a symbolic link is not mentioned
that means it is not supported due to being too platform specific (I
agree that perhaps it would be better to say this explicitly).

This was a convenient convention for what it was intended for, which
was extending an existing FITS multi-extension system for transporting
a telescope data stream to an archive, without having to redesign the
whole thing to use something other than FITS. If we had to do something
similar today I might prefer to use something more standard like ZIP as
the container, keeping the FITS part simple and focused on single files.
This would solve various problems such as providing a directory for
efficient random access to extract files from the container - probably
today it is no longer useful to attempt to do such a thing in FITS.
But the point here is merely to document existing conventions, so it
is not very useful to revisit such matters, except maybe as we consider
where to take FITS itself in the future.

- Doug