John wants two kinds of change to the TOC:

1. Ordering by title should exclude initial articles, and should use special titles for reviews. This will require that he provide me with a sorting title I can use for this purpose, so it's down to him to do that.
2. The single-page TOC to be split into Articles and Reviews.

I got 2) working today:

• There are two new items on the menu, Articles and Reviews, and each points to the same contents.htm, but with a different search parameter (type=article, type=review).
• The contents.xq code now reads that parameter, and filters the list of documents accordingly. It also includes that parameter value in a <classCode> element in the <teiHeader> of the output document, so the XSLT can find it.
• The site_doc_list_to_toc.xsl XSLT now provides a different title based on that parameter (from variables in the journal_globals.xsl file).
• It also uses that parameter as part of the JavaScript call in the table head cells' onclick events, so that the URLs called by these events now pass the type parameter back into the sitemap.
• The menu.js JavaScript has been slightly modified so that it can tell the difference between the two URLs. Previously it was discriminating on the basis of the bare filename; now it checks whether the href attribute in the link forms the first part of the current page filename, so the correct button ends up being depressed on the menu.
• The sitemap ended up not being modified at all.

This approach was about the third one I tried; it seems the most flexible (future requirements could add new values for the type attribute, and only small modifications would be needed to accommodate them), and doesn't change very much. The only oddity is the fact that on the Reviews page, which consists only of one document type ('review'), there's still a Type header/column. To suppress that would require that we check to see whether there's more than one value in the <classCode> elements in all the documents in the list. That would be easy with XSLT 2.0, using distinct-values, but it might be a bit of a kludge in 1.0, which is what this project is using. It is possible though, so we might do it in future.