> You could do that.  I was just saying that I don't feel we have
> explored enough the solution space...

This is definitely true for the types. But the other metadata (general
information and arglists) is basically a verbatim copy of part of the
text of the SRFI, just organized in a parseable S-expression format.
Even the structure in the S-expression file is much the same as the
structure in the document itself. So I ran out of things to add or
explore, unless you have something new in mind :)

> But then again, having some tools would be wonderful.  (But I would
> say to be prepared to scrape or rewrite them.)

Sure. We'll probably be constantly rewriting parts of them while we are
exploring :) Once the tools are stable we could publish them on
http://snow-fort.org/ if we can manage to write them in Scheme (as I hope).

I'll run the following experiment:

* Make a git repo for the (very work-in-progress) tool
* Make a git repo combining the official SRFI repos via 'git subtree'
* Edit some SRFIs in the combined repo using pull requests
* Add a Travis CI job to the repo so it runs the tool to check pull
requests.
* Make the tool generate a dashboard web page of the current status of
the master branch.

This will fairly accurately simulate the editing and checking workflow I
have in mind (of course the tools and HTML format would be improved a
lot later).

Git subtree ought to be great for editing the SRFIs. We can have
individual SRFI repos as subtrees of the combined repo, edit and commit
in the combined repo, then split off the right commits to the origin
repos easily when the time is right.

> I'm OK to focus on "announcing" just the HTML-related stuff.  However
> although we don't "announce" also the other meta-data, I do think we
> should have a pretty good idea (i.e. working tools and experimental
> sites) how the two inter-link together...

Great :)

I'll try to work on the tool prototypes and GitHub infrastructure so it
should be in demonstration form by roughly the same time you have a good
idea of what the XHTML structure would be. We could then combine them
(i.e. update the tools to read the XHTML instead of my ad-hoc classes).

Once you have a mostly stable XHTML structure, I'd be excited to try and
edit an SRFI into that form from scratch, to see what kind of process it
is and how long it takes. If we could get it to the point where it takes
30-60 minutes to edit an SRFI, it would be feasible to convert the
entire backlog to strict XHTML. (Arthur, if you have any objections at
this point, please tell us :)

If you or anybody else has any wishes or requirements for the tools, the
GitHub infra or the editing process, please chime in. This is all still
experimental.