The system should be compatible enough with web standards to allow some meaningful interoperability, e.g. import and export, with the rest of the web.

HTML, PDF and plain text are all very different in structure – lightweight markup languages were developed to bridge some of the gap between text and HTML. Word processor export to HTML varies enormously in quality and verbosity. If a knowledge commons is to be built in a reasonable time, there needs to be import from other formats. Unless there is effective export to other formats, people are likely to be cautious about committing time to what would be seen as a ‘walled garden’.

There is no need for a basic knowledge commons system to comply exactly with the full WHATWG version of the web page DOM. For export, it should be relatively easy for a knowledge commons wiki to export to a subset of HTML, and from there, existing software such as Pandoc can take it on to many different formats. Import looks potentially more troublesome. It is possible to filter HTML in various ways, so if a clearly defined subset of HTML can be mapped to the wiki format, it should be possible first to filter the HTML so that only those elements occurred, and then to convert into the wiki format.

It would make sense to me if wiki pages had a DOM representation consistent with the HTML generated by the wiki system, but I don't know how feasible this is.

Unfortunately, fedwiki sucks on this issue. Each paragraph-like element has a type, with a default type of ‘paragraph’ which is ended by a carriage return. However, two of the types are ‘HTML’ and ‘markdown’, and HTML in particular is able to produce very long and complex items, themselves including paragraphs and other material, without that being accessible to the fedwiki system. In essence, using the HTML element breaks the whole concept of paragraph entities. Lists are (at the time of writing) very hard to map onto lists elsewhere.