General Export Guidelines

1 Description

The general export guidelines should define how repository resource objects must implement import/export routines, how xml should be generated, how DTD/Schema files should be provided, how files are zipped and which common components must be used.

Export

Export features in ILIAS are provided on different levels. E.g.

• export of users in the administration
• export of learning modules in the repository
• export of members data in member lists

2 Status

• Scheduled for Release: Release Release 4.0 (Draft) / Release 4.1 (Final)
• Funding: Funded by Helmut Schmidt Universität, LEIFOS, PH Zürich
• Development: Feature is to be developed by Stefan Meyer, Alex Killing

3 Additional Information

• If you want to know more about this feature, its implementation or funding, please contact: killing (at) leifos.com

Alex 26 Feb 2010: I am currently working on generic export / dataset classes.

Goals are:

• Support a way to quickly implement new import/export features without the need to use XML writer classes or to write XML import parser classes.
• Allow the implementer to decide whether he wants to give the focus on performance (e.g. by reading data directly from DB in DataSet classes) or higher decoupling (by using existing application classes to retrieve data).
• Standard user interface

• Different standards and XML schemata
• Version control
• Support of container import/export
• Support for existing import/export routines
• Possibility to export to older ILIAS versions
• Detect whether it is possible to import a given package
• Relation to SOAP interface (XML representation)
• Relation to a (possible) JSON representation (e.g. used in Ajax calls)

1. Common data representation in a so called "DataSet" class
   • The DataSet class handles abstract representations of data that usually comes from/goes into the ILIAS database. The dataset class should support the following formats: Associative arrays, XML, JSON
     • A DataSet supports one or multiple entities for a ILIAS component. An entity is defined by:
     • Abstract field names and field types (not coupled with database field names). Types are e.g. integer, string, directory, ...
     • "Data records"
2. Export/Import classes. These classes use the XML representation of datasets and put them into package files including a manifest file that describes the overall structure and sequence of the import/export procedure. These classes should also be enabled to use other classes for XML creation than datasets (support existing code).

4 DTD/XMLSchema

Jour Fixe 12 Jan 2009: Currently we allow both, schema and DTD usage. The developer may decide which one is appropriate. But once a schema is introduced for a specific resource, it is not allowed to move back to a DTD. If both is equally appropriate we recommend to use a schema.

5 XML Structures

Common Header (Original Suggestion)

<Version ResourceType="crs" ExportVersion="3.6.0" MinCompliantTo="3.4.0" Nic="1234" Url="http://my.ilias.com/ilias3" />

26 Feb 2010, Current example of dataset representation:

<?xml version="1.0" encoding="utf-8"?>
<data_set install_id="4411" install_url="http://scott.local/ilias" top_entity="mob" xmlns:ns1="http://www.ilias.de/xml/..." ...>
  <types entity="mob" version="4.1.0">
    <ftype name="id" type="integer"/>
    <ftype name="title" type="text"/>
    <ftype name="description" type="text"/>
    <ftype name="dir" type="directory"/>
  </types>
  <types entity="mob_media_item" version="4.1.0">
    <ftype name="id" type="integer"/>
    <ftype name="mob_id" type="integer"/>
    ...
  </types>
  <rec entity="mob">
    <ns1:id>
      2494
    </ns1:id>
    <ns1:title>
      desktop.png
    </ns1:title>
    <ns1:description>
      image/png
    </ns1:description>
    <ns1:dir>
      Services/MediaObjects/set_1/dir_1
    </ns1:dir>
  </rec>
  <rec entity="mob_media_item">
    <ns2:id>
      114
    </ns2:id>
    <ns2:mob_id>
      2494
    </ns2:mob_id>
    <ns2:width>
      128
    </ns2:width>
    <ns2:height>
      128
    </ns2:height>
...

26 Feb 2009, Current example of manifest file:

1
2
3
4
5
6

<?xml version="1.0" encoding="utf-8"?>
<!--Generated by ILIAS XmlWriter-->
<manifest>
  <xmlfile component="Services/MediaObjects" path="Services/MediaObjects/set_1/dataset.xml"/>
  <xmlfile component="Modules/MediaPool" path="Modules/MediaPool/set_1/dataset.xml"/>
</manifest>

6 Import/Export functions

7 ZIP and Directory Structure

8 Data Format (Dates, ...)

Current Date/Time-Classes give relative dates like "Today"/"Yesterday". We need method that delivers an absolute date in a defined timezone. XML Export should always use "UTC" dates. HTML export should use user time zone, the time zone should be appended to the date/time by a method of the Date/Time classes.

9 User Interface

26 Feb 2010: The screenshots of the existing export screens (ILIAS 4.0) show some inconsistencies. Some of the screens use still the old table class. We should implement a general export user interface class, that already sets up the common screen:

• Use new table class
• Provide a table title
• Create/Add buttons are in a toolbar on top of the table (see Data Table Guideline)
• Different export formats are always presented as selection drop down list.

Screenshots

10 Implementation in ILIAS 4.1

The import/export framework is described in the development guide.

11 Suggestions for Guideline Extension

Matthias Kunkel, November 05, 2014: IMHO the export of a repository object should not only include the content but also the settings of an object. Settings are a fundamental part of each object. My suggestion is:
 
The export of a repository object has to contain the object settings, too. The import should adopt these settings as long as they are supported by the ILIAS version of the import installation.

Kunkel, Matthias [mkunkel], Dec 05, 2016: Export of blog now contains settings as well. Only open issue left: the names of blog authors. Every blog author is now called 'unknown' in the export.
I suggest to streamline this with the export of forums where we have a similar problem (exported content available at target installation but not user/author). In forums, user names are substituted by 'anonymous'. In both cases we destroy the history of communication because now one can understand how a conversation has taken place - who is answering whom or which postings are from different and which from the same user.
I see two options for the future (besides a unique label for the current user name substitution : unknown vs. anonymous):

1. We introduce a user name substitution guideline that always substitutes user names by an anonymous 'user xx' name. But for each active user in a forum or blog we use a different number: user01, user02 and so on. This will keep anonymity but allows to follow the discourse.
2. We implement option 1 and additionally give every user the option in the Personal Profile to allow the import of his or her real name. This should be a general setting for the entire platform. Default should be 'Don't show my name in export files'.

JourFixe, ILIAS [jourfixe], Dec 05, 2016: Due to the current technical concept it is not possible to distinct between several anonymous 'persons' without a big change of code. So the question is if this requirement is so important to invest suchr resources.