TIR Framing Program

In addition to tir index- and blog-generating programs, there needs to be a way to generate similar header, footer, and sidebar around ordinary document HTML content. Since portability requires static HTML documents rather than CGI or SSI dynamism, the program must produce HTML files combining content and tir framing blocks.

Am considering creating documents files as HTML fragments for insertion between <body>…</body> tags. The framing script would output a complete HTML file with the content fragment embedded in tir look-and-feel frame blocks. Would it be better to frame a document once then maintain the complete HTML file afterwards, or to maintain the fragment file (hidden from tir indexes) and reframe after each update?

Perhaps it's better to consider mkindex (in development as of 2006/7/20) as a prototype. Next iteration will generate only <body> fragment for directory index with output fed to the same framing program used for content HTML documents.

Copyright and license

Is it possible to determine copyright years programmatically for either hand-maintained or generated documents? Considering the complete HTML file as a material expression, is the copyright year the latest modify year on any of the files incorporated into the document, the last year the resulting document's content changed, the last year the resulting document's appearance changed, or ...?

Direction on copyright and license notices:

Don't automate copyright notice generation. Copyright year can only be determined on document-by-document basis. I don't even know if copyrignt has any meaning with regard to web page frame texts (header, sidebar, etc.), or to the web site as a whole.
Include explicit copyright notice in each content file. Use "copyright" division for HTML files.
Use copyright notice in .copyright file for generated files containing my content (e.g. .description file contents).
As a rule, a license notice (for content on which I wish to grant a license) should accompany the copyright notice, with a reference to the complete license text (per GFDL usage guidelines). Also, although I wish to contribute to the free software movement, I'm uncertain whether or not a free documentation license is appropriate or desirable for non-software-related content (blogs, family news, commentary, etc.). The above would favor explicit license notices in each document (or .license file for generated pages), like copyright notices, so that particular terms, or no license, could be selected as appropriate for the content.
On the other hand, if I could justify a single license for everything or most things on the site, a license notice could be incorporated in the standard page frame (footer?). An option is a site-wide <root>/.license file for all pages.
On the third (!) hand, what about planned semi-private content, like family news, that's intended for consumption by family amd friends only, and will be access-protected? It makes no sense to license material meant to be kept private. At the same time, if someone betrays my trust and divulges private information, I doubt copyright violation would be the best way to seek redress.
A middle way (?): Default is no license, but license can be explicitly stated in document, or optional .license file text will appear in frame for all documents in directory, allowing related documents to be bundled together with same, possibly unique license.