One solution to this is that when doing the diff I could first strip theThat seems reasonable. I agree with Ian that PBworks has a lot right with how they do things, including the page history and comparison of revisions.
The second issue involves sortable tables. Ideally, I'd like the wikiI thought so at first, and maybe still do for the Links. But the pre-Neo database had some useful tricks that might be hard to emulate in a Wiki table. Or maybe not, but one wouldn't ordinarily think of them in a wiki context.
One was to have separate authority to 1) add rows, 2) see rows, and 3) format the table. It was possible to give the moderators to determine the format of the table (including number of columns and column descriptions) while allowing members to add rows and edit their own rows only (not the rows added by other members).
It was even possible to give members the ability to add rows but not to see other members' rows - this effectively created a "drop-box" capability where members could share information privately with the moderators.
And, these detailed privilege settings were defined on a per-table basis. Or, perhaps the fact that these are per-table privileges provides the escape hatch necessary to allow this to work in a wiki environment. But that also opens up the question of what view/edit privilege controls should exist for a) the wiki feature as a whole and b) on a per-page basis.
Another set of useful capabilities came and went with the "Groups Labs" applications. Those were essentially extended function tables, where the columns were typed, had descriptions and edit hints, and other aspects of a more powerful database than the simple text cells of the regular Yahoo Groups Database feature. Didn't go as far as being relational though, nor being able to pull in content from the Members list or other inherent tables of the group.
To do that, you need to be able to create tables and be able to sortAs Ian said, PBworks does this too. They use what looks (in Source edit mode) like ordinary HTML table elements but declared with
<table class="pbSortable" ...
which presumably clues something in the page render to implement the table sort ability. I don't like the fact that the sort markers in the header row (arrows) don't show until you first click in a header row. If the capability is there the affordance should be evident.
Again, I can solve this problem by not using HTML pages and insteadI think most users will be best served with a WYSIWYG page editor, regardless of the underlying representation. With that in place it may be less important what markup language (HTML, markdown, ad-hoc) is behind it.
The other solution is to not try to combine the wiki and links/databaseAs hinted above, an advantage of a dedicated database section is that it makes wrangling the metadata clear: you can have a page view for each entry (row) that exposes metadata like author and date/time even if those aren't columns in the table view. And there's a clear meaning to the log entries that would go with editing a row's content or the table format.
I think if the table capability were wrapped in a wiki page that might be really powerful for some purposes, but I would want to preserve all the metadata power that the database form offers, something that PBworks' tables don't even aspire to do.
Those are the two issues I'm wrestling with at the moment. Thoughts orOne other feature of the PBworks' pages that I really love is the Table of Contents widget. Very handy indeed.