> As it stands I have tried to eliminate as much HTML as possible (which
> was used mainly for formatting purposes).  In the next days I'll take
> a look at how I can change the annotations to make it more maleable to
> exports and indexing.

This is great, but how would you integrate this into the current SRFI
process? The change in HTML structure would be very large. Would you
mandate this for new SRFIs, have editors convert submitted SRFIs to this
format by hand, or try to write an automated conversion tool?

> Because I still maintain my position that trying to extract more than
> basic metadata about the procedures described within, I'll simplify
> and remove extra classes or elements (if they exist).

I'm not sure which metadata you consider basic.

The tool I wrote relies only on plain text (in S-expression syntax) to
extract the names of arguments and return values, including optional /
rest arguments. It doesn't rely on HTML tags or classes for anything at
all. So whatever HTML structure you end up with, as long as you can pull
the plain text of a definition, its arguments can be extracted.

If you want to annotate it with a per-argument type or docstring, that
won't be as easy, but I would consider type annotations an optional
luxury in a dynamic language like Scheme, and per-argument docstrings
even a bit frivolous :) If we have a direct link to where the definition
is on the web page, that'd be plenty.