A brief technical infatuation

Ah! how disappointing when reality sets in, warts and all!

A week ago, no more, I was eagerly looking forward to learning a bit about Fedwiki. Having sat in on Ward's weekly session, Marc offered to introduce me to the system, and that he did, most generously, yesterday evening (my time). Thanks to Ward's hosting, I acquired my own test Fedwiki site, which welcomes visitors here. After that it was late for me, and no time to compose my thoughts. This morning, as I could have predicted, my head was buzzing with questions much before my usual time to wake up. So up I got, and (does this happen to other people?) I sat down at my desk and spent a long time doing everything apart from writing down my reflections on the Fedwiki system.

I've spent many years now dealing professionally with interoperability and technical standards, so when I finally got down to what I really was looking forward to, I started to poke around and see what hope there is for export and import of Fedwiki pages, which to me is a fundamental. Cetis (hint: ‘I’ stands for ‘interoperability’ and ‘S’ stands for ‘standards’) has been dealing with interoperability for over two decades now, and the not-so-grand narrative about data portability goes along like this. Say, a vendor has sold you a software system, which you use extensively and build up a whole lot of data within it. Then two years later, there is another vendor doing similar things better and less expensively. You want to move all your data from your old to the new system so you can start working with that. Can you? Well, that all depends. If you have taken the trouble to ensure that your first vendor's system exports information in a format which the second can read – in practice, this probably means they both have built in conformance to some (open) technical interoperability standard – then, no huge deal. But if they haven't, oh dear, you are, as they say, ‘locked-in’, and the first vendor has you at their mercy. And what about that not-quite-right experience involving .docx and .odt? If only Microsoft hadn't insisted on their own way…

What's the deal with ordinary web pages? A long story, to skim over quickly … the major browser vendors recognised over the years that there was little point in introducing HTML features which didn't work on other browsers, so they more-or-less agreed to abide by the W3C's recommendations. Then the W3C was starting to agree things they didn't like, so they formed a cabal, and created their own working group, under the title WHATWG. But at least they did agree on that, so currently a web page on one major browser looks pretty similar to the same page on another browser.

Of course, the web has become much more sophisticated since the old days when I learned and used to teach HTML. We can now program browsers to do clever things that are not just reading and rendering HTML. And it is by using these programming techniques, with some version of what started as Javascript, that Fedwiki works, not by storing pages in plain HTML.1 Javascript is related to a format for sending structured data between computers, called JSON. Now if you look carefully at the bottom of any Fedwiki page, you'll see those four letters, ‘JSON’, and if you click on them, up pops a box which represents exactly what the ‘page’ contains, in the Fedwiki way.

This is not at all how the big folk of the WHATWG think a web page is structured. They think it is much more complicated, and they've developed a ‘Document Object Model’ to spell that out. And Ward is happy with the Fedwiki model being much simpler than the standard DOM. Is that okay? Well … hmmm …

A Fedwiki page is essentially made up from a title, and a single, linear series of paragraphs, or paragraph-like things. In the Fedwiki JSON "story", these things have a "type". One Fedwiki "type" is even "html", meaning that you can embed sections of HTML right in your Fedwiki page. An HTML section can, naturally, include lots of HTML paragraphs, and lots of other things besides. And as well as "html" sections, there are lots of other shiny possibilities, including graphs, audio, video, calculator, map, and many more. Only a few of these types correspond directly to HTML entities.

Maybe I've given enough clues already about what this means for interoperability. To cut a long story short, it's not good news. I'm not trying to be purist. I would be happy if Fedwiki just implemented a small subset of HTML – lightweight markup languages do the same. But, as far as I can see, the different models of page structure, along with the shiny attractive curlicues that are so nice and powerful within Fedwiki, make consistent import from HTML to Fedwiki extremely difficult, though it must be possible in some way to export a Fedwiki page to HTML, because in a browser it is rendered in HTML.

If you view (in a browser) the page source for a whole Fedwiki page, you won't see the text content. Actually, in Firefox, if you select some text and then View Selection Source, you can see HTML along with the content. But it's not straightforward to do that. It's quite similar for some other highly interactive sites, where what you see is not what is written as a page, but is constructed on the fly from a database that sits in the background, from your point of view.

What I'm wondering now is what would need to be done to enable good export and import of HTML from and to Fedwiki. I'll ask around. Remember that I'm just thinking of the use of a wiki as a knowledge commons. For other uses, I think Fedwiki has a lot of potential, as I wrote in the last two entries. More next time.

Maybe, as in some worthwhile relationships, after the infatuation has dissolved, what can sometimes emerge, instead of wishing that the object of your desire had been all you wanted it to be, is an energy directed towards positive development and transformation.

I live in hope.

1: If you want to remember what HTML looks like, take almost any page in the browser and with the right mouse click menu choose ‘view page source’ or similar.

Topics: Interoperability; Wiki software

If you have any remarks on any of my posts, please send me e-mail, saying what you want me to do with your remarks. Are they private to you and me, or would you be happy to quote you (I will always attribute your words unless you ask me not to), and add your response (or parts of it) to the post it's about?
Creative Commons Licence