# General Principles¶

This document provides some basic knowledge about the Mumie system.

## 1 Documents and pseudo-documents¶

In Mumie, documents are entities with textual or binary content. (An exception are the so-called generic documents, which have no content. They are explained below.) Examples for documents are theorems, definitions, images or Java applets. Besides ordinary documents, Mumie knows so-called pseudo-documents. These are entities which can be treated formally as documents, but are not documents in the actual sense of the term. Examples are: users, user groups, semesters.

A special kind of documents are the so-called generic documents. They have no content of their own; rather, they are placeholders for "real" (i.e., non-generic) documents. These placeholders may be implemented by different real documents in different contexts. Generic documents are a means to implement two concepts in Mumie: internationalization and themes. The concepts are explained in the next section.

Each document or pseudo-document has a certain type and several meta-information. Types are explained in more detail in sections 3 and 4, meta-information in section 5.

Mumie has a simple build-in version control system for non-generic documents: If a document is checked-in for a second time, the former version it not replaced but saved. Thus, it is always possible to recover older versions.

## 2 Internationalization and themes¶

Internationalization means that the same content is available in different languages. Mumie realizes this by generic documents which are implemented by real documents in different languages. The following figure illustrates this with a simple example:

The theme concept allows for different appearances of the same content. A theme represents a certain web layout style. Thus, the theme controls things like fonts, background colors, button shapes, etc. The theme concept is realized by the same mechanism that realizes internationalization, too: generic documents implemented by different real documents for different themes.

If the user requests a generic document, the server checks which language and theme the user has selected, and tries to respond with the corresponding real document for the required language and theme. However, it may happen that the generic document is not implemented for all language-theme combinations. In that case, the server tries to find another real document which is nevertheless suitable to represent the requested generic document.

Here are the detailed rules for determining the real document for a given generic document:

1. If a real document exists for the required language and theme, that is selected.
2. Otherwise, if a real document exists for the required language and the default theme, that is selected (see below fore the term "default theme").
3. Otherwise, if a real document exists for the non-lingual language and the required theme, that is selected (see below for the term "non-lingual language").
4. Otherwise, if a real document exists for the non-lingual language and the default theme, that is selected.
5. Otherwise, if a real document exists for the default language and the required theme, that is selected (see below for the default language).
6. Otherwise, if a real document exists for the default language and the default theme, that is selected.

The default theme, default language and non-lingual language always exist. The default language can be set by the administrator when the Mumie sever is installed. The non-lingual language represents content which is not language specific. For example, CSS stylesheets usually do not contain any language specific content. The language code for the non-lingual language is "zxx" (language codes are the two- or three-letter codes to identify languages; i.e., "en" for English or "de" for German).

## 3 Document types¶

Each document or pseudo-document has a certain type. Types are characterized by names (internally by numbers, too).

Documents with a type name starting with generic_ are generic documents. All others are non-generic or "real" documents. We also speak of generic and non-generic document types.

For each generic document type a corresponding non-generic one exists. The latter emerges from the former by removing the generic_ from the beginning of the type name. A generic document can only be implemented by documents of the corresponding non-generic type.

It follows a list of all document types. First come the non-generic types, then the generic types, both in alphabetical order.

• applet
: A Java-Applet. The content is binary; it is a Jar archive containing the applet class file, perhaps class files needed by the applet, and supplementary resources like property files. Usually, applets have sources which also specify meta-informations (see subsection 2.5 and section 6).
• course
: A course. Represents a course as a document rather then a course as a organizational unit (the latter is represented by the pseudo-document class). A course consists of several course sections arranged in a net. The content is XML. Courses are created by the CourseCreater, a GUI tool for that purpose.
• course_section
: A course section, i.e., a subunit of a course. Consists of elements and subelements arranged in a net. The content is XML. Course sections are created by the CourseCreater (see course).
• css_stylesheet
: A CSS stylesheet. The content is XML (it is translated on-the-fly to the actual CSS format when the stylesheet is requested).
• element
: A mathematical content entity. There exist different kinds of elements, distinguished by the category metainfo. Examples are: theorem, definition, motivation. Elements are written in a special TeX dialect which is converted to XML by the mmtex tool. (Cf. section 5.) Thus, the actual content is in XML, created from sources in TeX.
• flash
: A Flash movie. The content is binary (the fla file).
• image
: An image. The content is binary (the image data) and may be in any of the following formats: PNG, JPEG, GIF, TIFF (the Mumie administrator can add more when the server is installed).
• jar
: A Jar archive. The content is binary (the jar file).
• java_class
: A single java class. The content is the class file. Documents of this type are used to implement correctors for problems.
• js_lib
: A JavaScript library. The content is XML (it is translated on-the-fly to the actual JavaScript code when the library is requested).
• page
: An ordinary web page. The content is in XHTML plus an extension XML. Documents of this type are used to implement auxiliary pages like the start page, framesets, etc.
• problem
: A mathematical problem. This document type is similar to element. There exist three different kinds of problems, distinguished by the category metainfo: applet, mchoice, and traditional. Problems of the first kind are edited in a Java applet. Problems of the second kind contain multiple-choice questions. Problems of the third kind are not edited online; rather, the user submits a written solution to a human corrector. Like elements, problems are written in TeX and translated to XML by the mmtex tool.
• sound
: An audio document. The content is binary (the sound data) and may be in the formats MPEG or WAF (the administrator can add more formats at build-time of the Mumie server).
• subelement
: A mathematical content sub-entity. Similar to element. Different kinds of subelements exist, distinguished by the category metainfo. Examples are: visualization, remark, example. Subelements are written in TeX and translated to XML by the mmtex tool.
• summary
: A summary of a course, course section or worksheet. Written in TeX and translated to XML by the mmtex tool.
• worksheet
: A worksheet, i.e., a collection of problems arranged in a net. Three different kinds exist, distinguished by the category meta-information: homework, prelearn, and selftest. The first describes a worksheet given as a homework to the students, the second a prelearning worksheet, and the third a worksheet with which the students can train and test themselves autonomously.
• xsl_stylesheet
: An XSL stylesheet. The content is in XSLT plus an extension XML.
• generic_css_stylesheet
: \\ A generic CSS stylesheet
• generic_element
: A generic mathematical content entity
• generic_image
: A generic image
• generic_page
: A generic web page
• generic_problem
: A generic problem
• generic_subelement
: A generic mathematical content sub-entity
• generic_summary
: A generic summary
• generic_xsl_stylesheet
: \\ A generic XSL stylesheet

## 4 Pseudo-document types¶

Here is a list of all pseudo-documents types in alphabetical order, with a short description for each:
• class
: A course in the sense of an organizational unit. A class has lecturers, students attending it, learning groups, and a semester it takes place in (see pseudo-document types tutorial and semester). Does not represent the contents of teaching; this is done by the document type course.
• language
: A language
• A section.
: Similar to a directory on your computer. Sections are explained in more detail later.
• semester
: A semester
• theme
: A theme (see section Internationalisation and Themes).
• tutorial
: A learning group of students of a class.
• user
: A user
• user_group
:A user group

## 5 Interrelation of (pseudo-)document types¶

Document and pseudo-document types are used to model teaching content and teaching activity in Mumie. The way they do that is best explained by the following uML digram:

## 6 Meta-informations¶

Each document or pseudo-document has a set of meta-informations or metainfos for short. Not all kinds of metainfo are defined for all types. For example, width and height are metainfos of images, but do not make sense for elements, so elements do not have this metainfos. The value of a metainfo may be a single item or a list of items.

On the Mumie server, metainfos are stored in several database tables. A representation of metainfos as XML exists, too. As a content developer, you will rarely come in contact with either of the both. However, you must specify metainfos in a special format in TeX or Java sources if you write documents of the respective types. This will be explained in more detail later.

Here is a list of all metainfos, in alphabetical order:

• Category
: Defined for: element, subelement, problem, worksheet, java_class. Distinguishes various "sub-types" of a document type. For example, an element can be a definition, theorem, lemma, application, motivation, or algorithm. This is specified by the category. See the next chapter for a detailed list of categories.
• Components
: Defined for all non-generic document types. List of documents needed by this document to operate. For example, if an element contains an image or applet, the latter is one of the elements components. Another example is a Jar needed by an applet: the Jar is a component of the applet.
• Contained in
: Defined for all (pseudo-)document types. The section the (pseudo-)document resides in.
• Content length
: Defined for all non-generic document types. Length of the content of the document, in bytes.
• Content type
: Defined for all non-generic document types. The internet media type of the content of the document. E.g., text/xml or image/png.
: Defined for all non-generic document types. A copyright note.
• Created
: Defined for all (pseudo-)document types. The time when the document or pseudo-document was created.
• Deleted
: Defined for all (pseudo-)document types. Boolean flag indicating that the (pseudo-)document is deleted.
• Description
: Defined for all (pseudo-)document types except user. Short description of the (pseudo-)document. Should be suitable to be displayed in a tooltip. If mathematical formulas are inevitable, write them in TeX enclosed in dollar characters.
• First name
: Only defined for user. The first name of the user.
• Id
: Defined for all (pseudo-)document types. The database id of the (pseudo-)document. Unique among (pseudo-)documents of the same type. The value is a non-negative integral number.
: Defined for all non-generic document types and all pseudo-document types. Time of the last modification of the document or pseudo-document.
: Defined for all non-generic document types. List of documents linked to by this document. Example: An element contains a hyperlink to another element. Then the latter is a link of the former.
: Only defined for user. The login name of the user.
• Name
: Name of the (pseudo-)document. Should be suitable to be displayed in a tooltip. If mathematical formulas are inevitable, write them in TeX enclosed in dollar characters. Defined for all (pseudo-)document types except user.
: Only defined for user. The password of the user. What is actually stored with this metainfo depends on the type of authentication the Mumie server uses. Usually, it is a hash code (e.g., MD5) of the password.
• Pure name
: Defined for all (pseudo-)document types. You can think of this as a filename without directory part and suffixes. Under this name, the document or pseudo-document occurs in the DB browser. The pure name is also the base for creating filenames when the (pseudo-)document is represented locally on your computer.
• Surname
: Only defined for user. The surname of the user.
: Defined for all non-generic document types. The version control thread the document belongs to. The version control thread comprises all documents which are different versions of each other.
• Version
: Defined for all non-generic document types. The version number of the document.

## 6 Categories¶

With the document type element, the following categories are possible:
• algorithm
• application
• definition
• lemma
• motivation
• theorem
With the document type subelement, the following categories are possible:
• deduction
• example
• history
• motivation
• proof
• remark
• visualization
With the document type problem, the following categories are possible:
• applet (editing is done in a Java applet)
• mchoice (multiple choice)
• program (programming problem)
• traditional (problem with wirtten solution and manual correction)
With the document type worksheet, the following categories are possible:
• homework
• prelearn
• selftest (correction can be triggered by user)

## 8 Section structure¶

Sections are similar to directories on a computer. A section can contain documents and pseudo-documents of any kind, including other sections; conversely, each document or pseudo-document is contained in exactly one section (the only exception is the root section which is explained in a few moments). Cycles with respect to the included-in relation are not allowed. This way, a hierarchical structure of sections emerges. It has a single origin, the so called root section. Thus, the structure has the form of a tree. Each document or pseudo-document can be found at exactly one place in the tree.

There is a certain standard for the section structure. Beyond the standard, the structure can be arranged arbitrarily. Below is an overview over the standard. The sections are specified by their pure names.

&lt;ROOT&gt;
|- system
|  |- common
|  |- libraries
|  |- languages
|  |- themes
|  |- document
|  |- pseudodoc
|  |- element
|  |- problem
|  |- course
|  '- misc
|
|- org
|  |- users
|  |- user_groups
|  |- &lt;institution&gt;
|  |  '- semester
|  |     |- classes
|  |     |- courses
|  |     '- tutorials
|  '- ...
|      '- content
|- &lt;institution&gt;
|  '- field
|     |- media
|     |  |- applets
|     |  |
|     |  '- images
|     |- problems
|     |  '- correctors
|     '- ...        '- ...The following list gives a short description of what the sections contain:
• system
: Pseudo-)documents which are of a technical nature (e.g., XSL and CSS stylesheets, layout images, themes, languages) or are needed to operate the server (start page, admin page, etc.)
• system/common
: Common resources (e.g., XSL and CSS stylesheets needed by several documents)
• system/libraries
: Libraries needed by clients (e.g., Jar archives, JavaScript libraries)
• system/languages
: Languages
• system/themes
:Themes
• system/document
: Resources for documents, e.g., XSL and CSS stylesheets for rendering documents, for displaying information about documents, or for creating forms to administrate documents. Note that documents of some types have their own subsections in the system section.
• system/pseudodoc
: Resources for pseudo-documents, e.g., XSL and CSS stylesheets for rendering pseudo-documents, for displaying information about pseudo-documents, or for creating forms to administrate pseudo-documents
• system/element
: Resources for elements and subelements
• system/problem
: Resources for problems
• system/course
: Resources for courses, course sections, and worksheets
: Resources for web frontends to administrate the Mumie server
• system/misc
: (Pseudo-)documents which do not fit into one of the above subsections of the systemsection
• org
: Pseudo-)documents of an organizational nature (users, user groups, classes, etc.)
• org/users
: Users
• org/user_groups
: User groups
• org/<institution>
: Everything related to the organizing of teaching in a certain institution. <institution> stands for a pure name adapted to the institution, e.g., "tu_berlin" for Technische Universität Berlin. If the server is shared by several institutions, there may be one such section for each institution.
• org/<institution>/<semester>
: (Pseudo-)documents for a certain semester. <semester> is to be replaced by a suitable notion for the semester, e.g., "susem_2007" for "summer semester 2007". In particular, this section contains the pseudo-document of type semester which represents the semester. There is one such section for each semester.
• org/uni/<semester>/classes
: Classes taking place in the semester corresponding to the parent section.
• org/uni/<semester>/courses
: Courses for the semester corresponding to the parent section.
• org/uni/<semester>/tutorials
: Tutorials taking place in the semester corresponding to the parent section.
• content
: The actual mathematical content (elements, subelements, problems, applets, images, etc.)
• content/<institution>
: Content made by or maintained by a certain institution. <institution> stands for a pure name adapted to the institution, e.g., "tu_berlin" for Technische Universität Berlin. If the server is shared by several institutions, there may be one such section for each institution.
• content/<institution>/<field>
: A thematic field of the content (e.g., linear algebra, analysis, probability).<field> is to be replaced by the actual pure name of the field (e.g., "linear_algebra"). There is one such section for each field. Each field section is usually the starting point for a deeper section structure which is motivated by field-specific considerations. This field-specific section structure is not subject to the standard. The standard only expects the two subsections "media" and "problems" explained below.

Add picture from clipboard (Maximum size: 500 MB)