The lay out of the documentation

Most of the LDAS software is written in c++, and therefore the documentation is naturally built around ``classes''. However, the LAL is written in c, and thus we cannot directly adopt the LDAS style of documentation. None the less, we try to mimic the style as close as possible by building the LAL documentation around header files and the modules and functions that include them. This choice is also natural because the hierarchical lay out of the documentation exactly follows the hierarchy of the code. [This is also the way books on programming in c document the c-libraries.]

• Documentation for the N'th package forms chapter N.
  
  
  • Documentation of header1.h in the package forms section N.1.
    
    • Documentation of Module1.1.c that ``#include's'' header1.h is in subsection N.1.1.
      
    • Documentation of Module1.2.c that ``#include's'' header1.h is in subsection N.1.2.
      
    • ... additional modules.
    
    
  • Documentation of header2.h in the package forms section. N.2.
    
    • Documentation of Module2.1.c that ``#include's'' header2.h is in subsection N.2.1.
      
    • Documentation of Module2.2.c that ``#include's'' header2.h is in subsection N.2.2.
      
    • ... additional modules
    
    
  • Documentation of header3.h in the package forms section. N.3.
    
    • ... additional modules
    
    
  • ... additional headers
  
  
• Documentation for the N+1'th package forms chapter N+1.
• ... additional packages

Note: Although the LAL-Spec is not rigid on the subject, it suggests that the number of modules and functions encompassed by a header file should be small: only ``small sets of related functions'' should share the same header file. This means for a given header-file section, there shouldn't be too many module subsections.