Feature Proposal: It would be really neat if Foswiki could fully support DITA publishing


I know it's somehow exotic to suggest using a (structured) Wiki (in the best sense) to work with something flexible as DITA, but for me the similarities between these two worlds were evident since the first day I read about DITA.

See also TWiki:Codev.DITA.

Description and Documentation

Provide a sophisticated Wiki Application for turning our beloved Wiki into a DITA reference implementation. smile





-- Contributors: FranzJosefGigler - 11 Nov 2008


Five years later, DITA is pretty popular. Foswiki support could help gain users.

-- VickiBrown - 17 Feb 2014

This is spurred by the Dita2Wiki project, a toolkit that enables you to publish DITA content (maps and topics) to a wiki. The project was founded 2008 and seems quite stalled atm. At least I don't find much indication of recent activity. The current toolkit only targets Confluence. Further more it is meant to publish from DITA content to a wiki. That's the opposite of what is described above.

Yet DITA and Foswiki often meet each other in the field of documentation. Foswiki is often used to maintain documentation of various kind in a collaborative environment. People have build up highly customized Foswikis to maintain a quality and publishing workflow to deliver documentation in various versions of various products. The problems here are manifold. One of the key advantages of Foswiki here is its flexibility to do things like these. DITA has it's main advantage in creating reusable documentation, content that can be sold along a product or as a product in itself, that is futher used in a production chain. Native Foswiki content isn't standard to do that. So exporting to DITA would allow to do so, a kind of wiki2dita.

From a very cursory point of view, both things might fit quite well as Foswiki is able to maintain structured content in a very flexible way. Alas the closer you dive into this, the more it becomes difficult to map Foswiki's concepts of structuredness onto DITA. I never went this approach to a full extend, but more promising seems to be to store native DITA documents as XML into Foswiki without transforming it two ways. Foswiki can be used as a storage for DITA documents solely, editing it online.

Which brings us to the DITA-Editor question. Any free and good enough web-based DITA editors out there? ... The most promising I've ever found is Xopus, now known as SDL LiveContent Create: proprietary and presumably only available embedded into a larger publishing framework. Too bad. As far as I know there is no good enough Open Source web-based DITA editor out there. If you know of one, then please let us know.

The editor question is pretty essential for DITA. DITA editors are so-called constraining editors that only allow you to edit well-formed documents that can be parsed and thus reused based on pre-defined schema definitions. This is in conflict with deeply rooted wiki concepts: the wiki presents the user a white area allowing you to quickly capture an idea without any additional fuzz. This is sometimes called "wikiness" informally: the higher the barriers to learn and add content, the lower the wikiness. A goal is to keep wikiness high.

With it comes the additional freedom by WYSIWYG editors, which quickly results in a soup of HTML and markup code. This kind of content is by far DITA-ready as it was created without any extra constraints. Constraints are essential to DITA. Without them users create exactly the kind of every-day wiki content that we see so commonly ... and which frankly isn't very reusable. So either you need a transformation of wiki content to DITA, or you create DITA content right away using a wiki-like content management system.

The task of bringing DITA & Wiki together goes far beyond the currently available (and abandoned) technical solutions.

The question is: either you establish DITA or you still allow free-form wiki editing. Both seem highly in conflict with each other.

-- MichaelDaum - 17 Feb 2014
Topic revision: r5 - 17 Feb 2014, MichaelDaum
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy