Last modified: 2010-05-15 15:37:52 UTC
The special pages should be able to be read by an application (such as a non-web client), whether it be in XML, RDF, or some other format. This obviously excludes Special:Export and Special:Import.
Created attachment 880 [details] Special:Allpages implementation (for XML) This is the first of several patches implementing this bug using XML. They are triggered by including "xml=yes" in the URL query. This one handles Special:Allpages. It returns exactly the same information as HTML (this includes initial range lists and such). None of the logic has changed. Also, in XML mode, it returns an HTTP status code of 300 Multiple Choices for range listings (in addition to a flag in the XML).
The special cases everywhere in this code are pretty ugly and will be hard to maintain. I'd recommend reworking this to a model-view system, with separate classes for handling HTML output and XML output, both separate from the database-reading work.
(In reply to comment #2) > The special cases everywhere in this code are pretty ugly and will be > hard to maintain. > > I'd recommend reworking this to a model-view system, with separate > classes for handling HTML output and XML output, both separate from the > database-reading work. I'll see what I can do with that. Currently, that special page is not OO, just a collection of functions. What I'm thinking is create a "PageLister" class (not final name!) and implement it for XML and HTML. Pass it to each of the functions, etc.
Created attachment 889 [details] Special:Allpages implementation (for XML) Added object described. Should be working. (Although such extensive changes should be tested.)
Please compare with Bug #3676, where I provided a patch for adding CSV support to most special pages with minimal effort.
(In reply to comment #5) > Please compare with Bug #3676, where I provided a patch for adding CSV support > to most special pages with minimal effort. I should note that unlike CSV, this is geared towards applications that can use XML with great ease (eg, AJAX apps). This is not only bots, but client-side readers as well. XML is also less ambiguous. You can specify exactly what each piece of data is, instead of infering that from it's position relative to other data. There is place for both. (CSV is simpler, XML has more well-distributed APIs.) Cooperation betweeen these two ideas would be very good. (gen=xml?)
I suspect we want to phase this out in favour of the new machine-readable API.
Sure. Then make this a tracking bug for special pages that do/don't comply. My concern is that if the data itself isn't easily parsed, then it amounts to glorified screen-scraping. If the API is directed at articles (in wikitext), then how do special pages fit into it?
(In reply to comment #8) > If the API is directed at articles (in wikitext), then how do special pages fit > into it? The API currently implements something similar to Special:Allpages (but with more filtering options), and most other special pages (or derivations thereof) are also implemented.
*** This bug has been marked as a duplicate of bug 14869 ***
