JT's neat little Java app for retrieving existing ids and proposed ids in TL's spreadsheets is a great idea, so I spent some of the weekend hacking at an XQuery version, and today completed, deployed and tested it. It now seems pretty robust (although it is dependent on the availability of a summary HTML spreadsheet from Google Docs, which isn't under the project's control). It will help contributors find a good proposed id for their new items in a pain-free manner, though.

I've departed from JT's practice in the following ways:

1. I allow for case errors in the spreadsheet. If you try "BOLD" with the Java app, it suggests "BOLD3", but the spreadsheet contains "BOLd3"; my implementation will catch that and suggest "BOLD4".
2. Where there are gaps in the existing and proposed numbering, I've elected to suggest number after the highest id; so for instance with STOW, where there are many ids, the highest being STOW156, I suggest "STOW157", while JT's app suggests "STOW18". I've done that because the gaps are often there due to old documents which have been retired; just in case they come back to life, or some link to them is out there in the wild, I've avoided them. But we can easily revisit this decision if you prefer the way the Java app works.
3. The page feeds back all the existing and proposed ids, with the existing ids as links. That means you can easily check for a document that might be on the same topic as the one you're creating, and it also means that if you want to choose one of the missing ids from a gapped run, you can see which ones exist and which don't.