Page MenuHomePhabricator

Wiki data storage and dynamic table display
Open, LowPublicFeature


Author: nospam.bugzilla

Some articles contain tables of data, and some contain several tables of the same data sorted
different ways (see the list of Eurovision winners as an example). Wouldn't it be lovely to
have a system to store tables of data, and a syntax in wikitext to render an output table
using this underlying table of data, with the possibility for the user to dynamically reorder
the table by clicking on a sort button?

Say we had the following table of data, in a simple XML format, envelopped into some special
wikitext tags on the page:

<wikidata ID="ESCwinners">
  <country code="CHE">Switzerland</country>
  <performer>Lys Assia</performer>
  <country code="NLD">Netherlands</country>
  <song>Net Als Toen</song>
  <performer>Corry Brokken</performer>
  <country code="FRA">France</country>
  <song>Dors, mon amour</song>
  <performer>André Claveau</performer>

And if you want to render this as a table you might put something like this in the wikitext,
with xpath expressions to describe which data we're actually pulling out for each column of
the table:

{| class="wikitable"
|- style="background:#efefef" datasource="wikidata[@ID='ESCwinners']"
! Year { sortbutton="winner/year" ascending } !! Country { sortbutton="winner/country" } !! 
Song !! Performer
|- winner/year || {{winner/country/@code}} || [[winner/song]] || [[winner/performer]]

So the idea then is that the table is filled with as many rows as there are child nodes
returned by evaluating the xpath expression in the datasource tag.

|- style="background:#efefef" datasource="wikidata[@ID='ESCwinners']"

The table header row will contain useful things like sort buttons.

! Year { sortbutton="winner/year" ascending } !! Country { sortbutton="winner/country" } !! 
Song !! Performer

When the text is rendered, the { sortbutton ... } tag will be replaced with an icon that the
user can click on to sort the table in ascending or descending order. The default sorting
for when the page is first rendered can be put in the tag of the page code.

Then the nodes/table rows are iterated over, and each new row of the table is filled with
data using the xpath expresisons in the row description code.

|- winner/year || {{winner/country/@code}} || [[winner/song]] || [[winner/performer]]

And there you have it. Of course, just using unbridled XML and xpath provides tons of
possiblities right out of the box, but it might be a bit much for the average editor. So
perhaps a more resicted syntax for the XML data and the table description markup would be
just as good. (Maybe it would be better to limit the XML data to element-centric or attribute-
centric formatting to keep it simple, for ex.)

So... well, I'm a programmer. Can't promise a lot of my time, but if this idea has any appeal
I could make an effort.


Version: unspecified
Severity: enhancement



Related Objects


Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:26 PM
bzimport set Reference to bz7777.
bzimport added a subscriber: Unknown Object (MLST).

djevrek wrote:

I think about this too, it will be very good to have some project like commons
for images, but for data. Let's say, number of goals of some football player and
something like that. And latter, on other projects we just use some sintax for
"calling" this data from that "main" data project.


nospam.bugzilla wrote:

That would definitely make it even more useful. Though I can see two disadvantages to a common data centre.

First, it would make it more difficult for a casual editor to see how to change the data.

More importantly, there would be a maintainability issue when changes are made to the data in the common database.
If someone decides that "goals" is too general and splits the data into "kicked goals", "headbutts", "penalties",
etc. and they only think that one article uses this data, it could break the tables in other articles that use
this data. If the data and table description are obligatorily in the same page, then the editor will see the full
effect of their changes right away.

Looking at the problem from a different angle, editors should feel confident that they can make changes without
breaking something. Otherwise, they might be discouraged from adding useful information.

But on the positive side, it is a very attractive idea to have all this data centralised so that different pages
(on different subjects, or the same subject in different languages) call the same unique data. So maybe there is
a way to work around the problems...

ayg wrote:

This is hardly a new idea; it's been thrown around for a few years now. See
[[m:Wikidata]], and (for two currently-maintained attempts at an incarnation)
the extensions "Semantic MediaWiki" and "WiktionaryZ". The major problems this
has faced so far are technical: getting people to write it and making sure it's
efficient enough to run acceptably.

I guess there's no bug for this, so this may as well stay open, but see the
product MediaWiki extensions, components WiktionaryZ and Semantic MediaWiki.

Please have a look at for an extension
that I am currently developing that seems to do what you are asking.

It's still in the early stages, so not completely working and not particularly
optimised. Feedback is welcome.

gero.scholz wrote:

Please have a look at the latest version of DynamicPageList at

The idea is that you DO NOT HAVE TO USE extra syntax, but create reports from existing wiki elements like headings, categories, links and template invocations.
The combination of these four elements - together with contents transclusion - is quite powerful.

You can easily write a DPL query which lists a certain chapter of every article which belongs to category "Poet" or uses a template called "Poet" and contains a
link to another article called "Dublin". You can show arguments which are passed to the template "Poet" (using a different template) and you can transclude
chapters with headings like "work" or "life".

  • Bug 6237 has been marked as a duplicate of this bug. ***
matmarex set Security to None.

WikiDB is now very mature, and I think it covers everything in the original request, and more besides:

It does not require unwieldy XML in order to define data - a lot of the syntax elements have been chosen to fit with existing wiki syntax, and where new syntax was required it has been kept as simple as possible.

The extension is still being actively developed, and I would be happy to accommodate any changes that may be required in order to fulfil the brief, providing they do not substantially change the nature of the extension.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:01 AM