> So we could have either:
>
> 2) Two S-expression files (e.g. "manual.scm" and "final.scm" for lack of
> better names). The tool would take the HTML file and "manual.scm" and
> merge them into "final.scm"). It would touch neither the HTML file nor
> "manual.scm".
>
> Approach 2 might be cleaner [...]

I now have an example of approach 2 for SRFI 1 here:
<https://github.com/lassik/srfi-markup-proposal/tree/master/arglist-generator>

The human-created additional metadata file:
<https://github.com/lassik/srfi-markup-proposal/blob/master/arglist-generator/srfi-1-meta-add.scm>

The fully machine-written combination of the SRFI HTML and the above
human-created additions:
<https://github.com/lassik/srfi-markup-proposal/blob/master/arglist-generator/srfi-1-meta.scm>

The final form <srfi-1-meta.scm> includes all data mentioned in Arthur's
<https://github.com/scheme-requests-for-implementation/srfi-common/blob/master/admin/srfi-data.scm>
summary file (as far as I can tell).

I encoded each date as a list of integers: (year month day)

I added some more classes to the HTML to help extract some of the
general information about the SRFI. If we adopt Ciprian's XHTML layout
we could instead rely on a standard tag structure.

Personally, I'm pleased with the way this format turned out and would
consider it almost done for publication. If you want any changes or
additions, please don't hesitate to say so :)

Obviously the right HTML structure is still left to be worked out, but
this S-expression form can be generated from any HTML form we come up
with, so the two forms can be developed independently.