Skip to content

import_mobius.py Documentation

Introduction

import_mobius.py is the Nobius import tool for bringing a Mobius assessment back into Nobius JSON. It accepts either a raw Mobius XML group file or, preferably, an exported Mobius ZIP containing manifest.xml and web_folders.

The importer works on standard Mobius exports. When the export was originally generated by Nobius, import fidelity is much higher because the question HTML contains additional structural annotations such as data-propname. Plain Mobius-authored exports can still be imported, but the recovered JSON may be simpler and the import may produce more warnings.

Prerequisites

In order to use this tool, Python 3.6 or higher is required. Additionally a few modules need to be installed:

  • bs4 or BeautifulSoup. This is a parser used to get HTML and XML attributes from the question files.
  • lxml. This is used with BeautifulSoup to parse the XML and recover manifest line numbers for reporting.

Both these modules can be installed using pip:

python -m pip install bs4 lxml

Usage

To use this tool, run it from the Nobius repository root or from inside the Nobius/ directory:

python import_mobius.py FILEPATH -d DESTINATION --no-uid --config CONFIG

Where:

  • FILEPATH is a required argument, showing the path to the XML file or exported ZIP to be imported.
  • DESTINATION is an optional argument, given by the -d or --destination flag, telling the script where to write the JSON files to. By default, this is the same directory as the source input.
  • --no-uid is an optional flag, telling the script to remove all uid properties from the imported JSON files. This is useful if you wish to create a completely new group that will not overwrite the current one in Mobius.
  • --config is an optional path to a Nobius config file. By default the tool looks for nobius.json in the repo root.

Output structure

For a simple single-assignment export, the importer writes one sheet folder containing:

  • SheetInfo.json
  • one JSON file per imported question
  • media/ when referenced media is copied

For course-module style exports, the importer follows the exported hierarchy:

  • one top-level folder per assignmentUnit
  • if a unit contains a single assignment, the questions are written directly into that unit folder
  • if a unit contains multiple assignments or question banks, the importer creates nested subfolders under that unit, one per assignment

Fallback names are used when the export does not provide good names:

  • unnamed units become Default Unit
  • unnamed assignments become set1, set2, and so on

Import report

The script writes import_report.json and import_report.txt into the destination directory.

These reports include:

  • warnings raised during HTML/XML reconstruction
  • informational recovery and normalization notes
  • copied media and missing media
  • all written output paths
  • processing context for warnings

In import_report.txt, warnings include the item being processed and, where available, the source location in the export manifest, for example:

- Response area tag couldn't be found in element. [question: 1 Lock | manifest.xml:1024 | parts.1.response]

This makes it easier to trace problems back to the exact question, assignment, or unit in the exported package.

The text report now separates:

  • Warnings: unresolved problems or cases that may still need review
  • Info: successful recovery or normalization steps, for example when a response placeholder or mark annotation was recovered from split statement fragments

Round-trip workflow

The intended workflow for supported content is:

  1. Render a Nobius sheet to Mobius with export_mobius.py. For a different export profile, use export_mobius.py --profile exam.
  2. Export that assessment from Mobius as a ZIP.
  3. Import the ZIP back into Nobius with import_mobius.py.
  4. Review import_report.txt for warnings.
  5. Re-render the imported folder if you want to confirm that the sheet still round-trips cleanly.

The importer is designed for Mobius exports, with the best reconstruction quality on Nobius-generated assessments that may have been adjusted in Mobius. It is not intended to recover arbitrary Mobius-native authoring with perfect fidelity.

Supported round-trip targets now include:

  • standard response areas already modeled by Nobius
  • custom response layouts
  • structured tutorial links
  • HTML response components authored through Nobius
  • document upload components authored through Nobius

Practical limits

Some exports are still inherently lossy or ambiguous on re-import. Common examples are:

  • plain Mobius-authored questions with no Nobius data-propname markers
  • questions whose HTML no longer preserves clean part wrappers
  • merged or heavily edited platform-side content that still renders in Mobius but no longer exposes enough structure for exact Nobius reconstruction

In these cases, the importer will usually still recover usable JSON, but it may fall back to minimal question structure and emit warnings in the report.

For the template-side constraints that preserve high-fidelity round-tripping, see Round-Trip Invariants.