4

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.

Related

  • For what it's worth, I'd be more than happy to provide a baseline for this new format. I'm going to be creating the XML database, anyway. – Sean Allred Jul 22 '14 at 17:45

You must log in to answer this question.

Browse other questions tagged .