Peter Blaise responds: Thank you! It's wonderful to see so much careful, conscientious thought go into the integration of wiki elements in one discussion. To continue the exploration: I'm concerned about how and why to put any data IN to a wiki in the first place. I know that any automation system can only answer questions it was pre-told how to answer. For example, one goal is to be able to print a group of pages as a book, but edit them as separate pages. I think you are saying that the MediaWiki print feature does not assist in doing that grouping for printing in one-step. And, neither do any of the other features - namespace, category, sub-page - assist in grouping the wiki's contents for one-step collected output. Standing back and revisiting what MediaWiki is all about, the Wikipedia.org implementation or MediaWiki seems definitive: a bunch of separate pages that are somewhat findable with basic word searches. The Wikipedia's goal is to present one page at a time on screen for the visiting user of the wiki software. Also, in order to facilitate (not automate) sequential (not one-step) editing or printing, there are "gathering" features (such as namespace, category, sub-page, and special:pages) that allow a user to cycle through a series of tasks to execute them over a group of individual pages, but still manually executing whatever they are doing one page at a time. (This is why editing and system administration are so time consuming, right?) And I didn't even mention global search and replace! In other words, the native skills of MediaWiki (I'm supporting v1.9.3 through v1.10 so far) are page oriented, and any desire to search/sort/select groups of pages and treat them as an entity for printing or exporting would require supplemental PHP/SQL programming outside MediaWiki. Have I got it? Peter Blaise asks: Toolserver? Waaa#1: One frustration is typing any vocabulary word into the search bar at MediaWiki.org and getting ... nothing! However, within the wording of a few page links, I found http://meta.wikimedia.org/wiki/Toolserver - yes, that's at wikimedia.org, not at mediawiki.org! Waaa#2: Of course, then, another frustration is having so much stuff that's supporting MediaWiki.org (the software) being hosted at Wikimedia.org (the Foundation). This splits the community in two. Actually, there's great MediaWiki support stuff exclusively at Wikipedia.org (the project), so the MediaWiki (the software) support community is at least divided in three! Waaa#3: Another frustration is hidden links that do not show on screen, or for cut and paste, and often do not show when printing (I read copious printouts and highlight links on paper to search later). That page link (above) says: "Please see Toolserver/Projects for a list of available tools and other content." ... but there is no clue that the word "Toolserver/Projects" is a link. Same on the subsequent Toolserver/Projects page, er, on the http://meta.wikimedia.org/wiki/Toolserver/Projects page which offers the words "Toolserver/TStoc" and "TSTOC". Both are invisible links, namely to http://meta.wikimedia.org/wiki/Toolserver/TStoc and http://tools.wikimedia.de/~interiot/cgi-bin/tstoc I appreciate we all have different preferences in response to "ugly" http links. But, I find it very frustrating to not have them fully displayed and printed or at least underlined so I know there's a link there. Waaaaaa! I will not calm down! Okay, okay, back to the discussion. (Please see http://www.webworksite.com/articles/article4.php before responding to my "complaints", PLEASE!) Peter Blaise responds: This is why I mentioned Quicken for DOS, that o'l relational database software I've been using, same copy, since the 1980s. It's nothing but a relational database with incredible powers in it's "category" and "class" structure for transaction searching/sorting/selecting for output. Analogy wise, a wiki page is like a Quicken transaction; a namespace is like a Quicken register/bank account. Why with a modern SQL database, excuse me, an "RDBMS", are wiki categories so powerless? If anyone doing development for MediaWiki has no experience with this 20-year old Quicken for DOS, I'm happy to send you a copy (it fits on a single floppy) for demonstration and education purposes. I'm serious. I'm so used to the incredible sophistication of this 20-year old DOS program that it heightens my frustration when a modern wiki is way naive in comparison. (Again, please see http://www.webworksite.com/articles/article4.php before responding to my "complaints", PLEASE!) Peter Blaise responds: Wow - I've got some more reading to do! Thank you very much. With all these extensions to study, I feel like I'm shopping with a small shopping basket in a big store - like figuring out which Firefox extensions to get and keep, and which to ignore or delete (~2,250 at last count). Peter Blaise responds: I know this first hand. But, my wikis are starting life being fully populated from legacy documents. Immediately, end users are asking, "How can I do this, and how can I do that, and ..." ...and so on. All they are asking for is the same tasks they are used to doing with their information using other software. I'm stymied when it comes to the wiki features and benefits in comparison. "Great question!" is all I can say to the end user ... then start a new round of research and development. Here's a sample challenge (simplified example). Say I have an in-house wiki and an ... out house wiki, for lack of a better term. RDBMS wise, they both may need access to zip codes, but otherwise, their data may need to be separate from each other. I could have them both look at the same zip code namespace, but keep each other out of each other's namespaces (I think). (Or is this better handles with separate wikis using the same MySQL?) Or, a computer "data elements dictionary" wiki. I've got multiple databases to document. Each database to be documented may have similar table-names and element/column-names. I could make each database a separate page. Then I could make each element a sub-page of that database. That way I can have, say, 2 elements both called "Name_last". One is under Database_inhouse/Name_last. The other is under Database_outhouse/Name_last. Over time, the authors of those commonly named documents might diverge on the meaning and criteria of the data elements in their own databases. One database may even be shut down and be retired, deleted from the wiki, with all sub-pages included. In one fell swoop? No. That doesn't work! The sub-pages hang around, as orphans of a non-page, don't they? (Also, I don't see any links from the master page to it's sub-pages, nor from sub-pages to the master page. How to make them appear like at the top like http://meta.wikimedia.org/wiki/Toolserver/Projects that shows a "< Toolserver" link at the top of the Projects page to go "up" one page?!?) Or, should the different databases go into separate namespaces? I wouldn't want "Name_last" as a single page in the root common to both databases since their uses in each database might diverge, and the authors may have different instructions for each different use. Ahh. Endless, eh? Anyway, the above is why I'm trying to find or build the answers. No analogy is perfect. It's not simply a "how to drive a car" manual I'm after. Nor "how to tune up your car" nor "how to design a car". But, perhaps a wise combination of all these, plus "why travel" and "transportation for personal pleasure", as well as "transporting goods and services" thrown in as introductory and overriding themes throughout. I can't imagine that's very difficult to do. Not with everybody pitching in on a wiki-based environment. ;-) Thanks for your insights, Brianna and everyone. Very stimulating and challenging. I look forward to having as much to give back as I'm getting. -- Peter Blaise