PKP 2017 Sprint Report: Upgrading OJS XML Import/Export

September 27th, 2017 by  | Comments Off on PKP 2017 Sprint Report: Upgrading OJS XML Import/Export

Special thanks to this group’s participants: Mark Jordan and Dimitris Efstathiou

During the PKP 2017 Conference Sprint Sessions, one of the tasks we decided to work on was the development of a process which, given a natively exported OJS 2.x XML file, the OJS 3.x natively exported XML file is being created.

The developed process targets especially the PKP’s Private LOCKSS network internal procedures, like the open availability of inaccessible journals process. The PKP Private LOCKSS network collects and preserves OJS Journals that use OJS version 2.4.8 and above. In the case of a collected Journal’s inaccessibility, PKP can, after a certain series of administrative steps, use the preserved data of this journal to make its content publicly accessible again.

For system maintenance and security purposes, it is possible that PKP will want to upgrade the preserved content to the latest OJS version. This could be a challenge in the case of 2.x preserved content.

The team decided to follow a systemic way to deal with the problem (rather than a software/coding approach). Image 1 shows the strategy of this approach.

Having an OJS 2.x exported XML, the team decided to use the already existing OJS tools and processes to

  1. Import that XML to a newly created OJS 2.x installation
  2. Upgrade this installation to OJS 3.x
  3. Export the native OJS3.x XML file and save it (or use it)

The script created for that can be found at https://github.com/defstat/pkppln_vagrant/tree/pkp2017-sprint-ojs2-to-ojs3, and uses Vagrant scripting to automate the process (https://www.vagrantup.com/).

The main advantages of this strategy are:

  • The team is using scripting to automate the process, so that it could be easily integrated to a more general infrastructure procedure.
  • The solution does not need code maintenance as it uses already developed and maintained OJS tools.
  • The solution is not bound to a certain OJS version target
  • The solution can use any “chain of import/upgrades” in the case that in the future 2.x OJS installation upgrades to OJS x.x will not be supported.

Future Work

The developed process can be extended, for example with:

  • Parameter for import and target OJS version
  • Development of batch XML process (the current script only uses one)
  • Integration to an automated re-activation of preserved Journals

 

Tags:

Comments are closed.