This would make it much easier to create the bulk of language-specific wrappers (using a different XSLT or your favourite XML parsing tool). As it stands now, the documentation contains little semantic meaning within the source and makes it needlessly difficult to scrape through. A little bit of XSLT/CSS could solve this handily.
I have been working on a scraper in Python that is attempting to work with the current system. It can and should be used to perform the great bulk of the work if this gets a green-light.
(Believe it or not, this is a version 3 overhaul of the scraper, probably the final such overhaul if the documentation isn't re-factored. Much of the implementation remains and will be completed tonight, but I believe the general approach now is solid.)
History
I will note that earlier versions of the API were reflective; you could make an API request that returned all API information. This proved to be too much effort to maintain. I don't propose this be brought back; I agree that it would too much to maintain within the API itself, but perhaps it would not be out of the question to just maintain a downloadable XML database of the API and have XSLT/XHTML present it for the browser.
