Question

I have a website that is produced from XML... in addition some pages contain links to binary attachments.

I am investigating the possibility of migrating this data to a TWiki instance.

I am fairly experienced when it comes to XML related technologies but have zero background when it comes to perl.

But what I see is that the twiki pages basically exist as text files so there could be a XSL Transform that could take place to change the XML to the txt format twiki requires.

What I am also aware of is that I am guessing that various other updates would be required to other text files that store information on the website.

What I am looking for are tips on what parts of the website would require updating if trying to perform this.

I hope the info I have provided is clear if not please let me know.... thanks

Environment

-- TWikiGuest - 26 Apr 2007

Answer

If you answer a question - or have a question you asked answered by someone - please remember to edit the page and set the status to answered. The status is in a drop-down list below the edit box.

If I understand you correctly then you want to make a "once-and-forever" migration. This should be really straightforward, without any need for Perl knowledge. It is just a matter of whether you want any "fine tuning" around the edges.

• If you want to put your XML sourced files into a separate web, create that web first with TWiki's own function (see TWiki.ManagingWebs). This will create all the "management topics" (WebHome, WebPreferences) for you. You could later even overwrite your WebHome.txt file if your XML process produces its own "homepage".
• Let your XSLT process produce text output, and take special care for spaces and linefeeds: TWiki's text files are line oriented, and newlines within lists or tables can spoil things. Lists have to start with exactly 3*n spaces.
• Take care for "consistent" encoding between your XSLT output declaration and your TWiki configuration.
• You do not have to update anything beyond the .txt files for a start. Things like the index or searches are done in "real time" and will work immediately.
• Attachments can be migrated directly by moving them to the appropriate pub directory. Probably you'll have to create the directories in advance. Take any example .txt file with an attachment to examine how they are linked.
• Take care for file permissions: For TWiki operation, all .txt files and attachments, and their directories, must be writeable by the user id of Apache.
• Make sure that all .txt files start with an uppercase letter.

With this procedure, TWiki users should be able to view, and to edit, the files right from the start. After the first edit the RCS history file (extension .txt,v) will be created automatically by TWiki; that's why the directory must be writeable by Apache. The missing features are (maybe the list is incomplete):

• Neither the text files nor the attachments have a "history", of course. If you want you can create that by checking the files in with the appropriate RCS command, like TWiki does.
• There is no mail notification for your initial file creation. This would be a problem only if you regularly add or change files with your XML process, but not for a one-shot migration.

-- HaraldJoerg - 26 Apr 2007

If you create a generic solution we'd love to see a XmlToTWikiAddOn or XmlToTWikiPlugin posted in the Plugins web on twiki.org.

See also Tag:import and Tag:xml.

-- PeterThoeny - 26 Apr 2007

A generic solution would be too difficult, since the transformations heavily depend on the source schema. I am not sure whether there are sufficiently popular ones around. Docbook comes into my mind, which would give a hell of a stylesheet, or XHTML, accompanied by all the problems known from the Wysiwyg HTML to TML roundtrips. There are plugins which do XML conversion "on the fly" (SablotronPlugin and XmlXslPlugin), but neither is suitable if you have an actual migration with a possibility for subsequent TWiki editing in mind.

The best I could think of is to create named (i.e. callable) =<xsl:template...> elements which serve to convert contents passed as parameters to TML snippets, e.g. for internal links in brackets (especially when chunking), lists, tables, attachment specifications, and so on.

-- HaraldJoerg - 27 Apr 2007