File Representation

ADI has a concept of file representation. Different representations correspond to fundamentally different file formats, such as HDS, FITS or ascii text. When you specify a filename chances are there will be only one valid interpretation of that filename, but this is not guaranteed. For example, you could have an ascii file called myfile.data and an HDS file called myfile.sdf with a top-level component called data in the same directory. The behaviour of ADI when a filename ambiguity occurs is discussed in Section . The mechanism for resolving the ambiguity is to append the file representation code to the filename, for example,

   myfile.data%ascii
   myfile.data%hds

   myfile                        ; myfile.sdf top level, extension assumed
   myfile.data_array             ; a top-level component
   myfile.variance(1:10,2:*)     ; a slice of an array

   myfile                        ; the whole FITS file - .fits is assumed
   myfile.pha[1]                 ; whole name of file needed, use first
                                   FITS extension only
   myfile.pha+1                  ; Alternative version of above
   myfile.pha[1]%fits            ; as above if ambiguous representation
                                   (not very likely!)
   myfile.pha^BITPIX             ; specific keyword 
   myfile.pha[3]^NEVENTS         ; specific keyword in extension

Once ADI has opened the named file object it attempts to derive its natural class. This is implemented as sequence of rules mapping attributes of the opened file (such as HDS type or the FITS HDU class keywords) to ADI class names. If a natural class can be defined, and that class is the one requested by the application then the search is over. If the natural class is different, then ADI searches for intermediate routes to go from the natural class to the requested class, constructing an analogue of the topology shown in the third example on Figure 1. In the absence of a natural class ADI attempts to connect the file object directly to an instance of the class requested.

File representation can be propagated in different ways, depending on the way in which output files are derived. Options can range from "all outputs must be HDS" type statements to "inherit the representation from the input file if the output is derived from it, otherwise use FITS". This can all be done in a fashion which is class dependant (you might always want spectra in XSPEC format, but images in HDS for example).