Due to the distributed, collaborative nature of this project, it is critical to capture the semantics of the authors' work, rather than presentation-specific syntax. This encourages authors to concern themselves with the meaning and structure of their content, rather than the notation and how it will look. Towards this end, we have adopted the eXtensible Markup Language (XML)6 for our material in general, and specifically content MathML11 for mathematics. We have developed a lightweight document markup language called CNXML3 for storing the basic document structure, incorporating content MathML via the XML namespace mechanism16 to mark up any mathematics present in the module.

The use of XML has several advantages. The content may be stored in a single source format and styled for multiple output modalities: web, print, ebook, audio, or even future formats not yet defined. This flexibility is key in freeing us to devise new means of visualizing information without being concerned with compatibility with particular browsers, or designing to the lowest common denominator functionality of older browsers. Adapting our content to a new visualization capability requires developing a new stylesheet, rather than than recoding and transforming documents en masse.

This separation of content and style also allows for a coherent presentation of materials from many authors, including mathematical notation. If multiple authors were to write modules using their own preferred mathematical notation, instructors would be constrained to assembling courses with internal notational inconsistencies. Such discontinuities are very disruptive for students, causing cognitive dissonance and dramatically slowing learning and their attainment of educational goals. By using content MathML and the XML Stylesheet Language for Transformations (XSLT)29, we allow instructors to create courses with consistent notation throughout, independent of the notational preferences of the various original authors.

Authors

Connexions module authors take advantage of our web-based collaborative editing system to create, share, and maintain modules in the repository. This system is based on Zope31, a web application server platform. Using the editing system, authors form workgroups to collaborate on modules and courses, sharing ideas and swapping successive versions until they feel the content is ready to be submitted to the repository (See Fig. 2 .) The interface provides facilities for entering module metadata as well as for editing the text of the module itself. It also allows authors to list related materials to be presented as auxiliary links (See students for details.) The interface also provides a download/upload feature for the module text so those who dislike editing in a browser window may use an external editor. Since XML is an open standard, we need not require any particular editing software, and authors may use the editor of their choice. With XML's wide industry support, several editors have emerged. Many of these are geared mainly toward tree-structured data entry, but some do provide a fair document markup interface (Morphon15, XXE28) These are still unacceptable for handling MathML, however, where a specialized editor is required.

Figure 2 Authoring Work Flow

We have explored several avenues for producing content MathML. The text editor Emacs has an XML editing mode20 that many of our staff use, although we wouldn't recommend this for non-technical users. Many mathematics manipulation packages (Mathematica10, Maple24, MathCAD9) provide MathML export capabilities, but often the output is only available as presentation MathML. We have looked at two dedicated math-entry programs: WebEQ25 and EZMath12. WebEQ's input is more geared towards presentation, but it does attempt to generate content MathML, interpreting the the author's intent and providing some visual feedback when the meaning is unclear. EZMath takes a novel approach, requiring input in a natural-language style instead of a using a graphical interface. Since it retains the semantic content, it has no difficulty outputting content MathML, although it does require the user to learn a new syntax. In addition to improved content MathML support, we would like to see two features in MathML editors. The first is better extensibility, including support for csymbol tags and OpenMath17 definitions. The second is better integration with other general-purpose XML editors, perhaps as a plugin.

Instructors

An instructor's role in the Connexions system is to serve as a guide for their students through the sea of modules. They do this by using our Course Composer software to build touring itineraries or "coursepaths". Instructors build up chapters and courses by combining modules written by other authors with their own material. In addition, Course Composer lets instructors provide additional links on the modules in their course, beyond what the original authors have specified. These "instructor-imposed" links are course-specific, and stored without modifying the original modules. Each imposed link belongs to an instructor-specified category (such as "supplemental" or "prerequisite") and can be assigned a number from one to five indicating the strength or relatedness of the link. These links are then presented to the students to help them understand the relationships between materials and to encourage individual exploration. The Course Composer creates a course description file out of the imposed links along with the selected course path. The repository stores the course description file in the Resource Description Framework (RDF)22 format for student access.

One potential hurdle in assembling materials from different authors is mismatched notation. Connexions solves this problem by utilizing content MathML. The repository stores only semantic information, leaving notation and presentation specifics up to the instructor. Instructors are allowed (and encouraged) to specify both cosmetic and notational parameters for displaying their course (eg. background color, or the use of vs. for .) Course Composer stores these choices in the course description file. They are then used to select an XSLT stylesheet (and possibly a set of passed parameters) to transform the course for display. In this way the instructor can customize the the course to his or her taste, achieving a consistent presentation. This is a limited implementation of the techniques described by Naylor and Watt14.

In addition to electronic display on the web, instructors may wish to provide a printed version of the material. This can easily be done from the same source, thanks to the separation of content from presentation. We use XSLT stylesheets to transform the RDF course description file and the course modules (stored in CNXML and content MathML) into a single file consisting of XSLFO7 and presentation MathML. This is than fed to passivetex18, creating a PDF file that can be sent to Kinko's or a university press or printshop for printing and distribution to the students. Documents produced this way achieve high quality mathematics layout thanks to the TeX23 rendering engine, and can have autogenerated tables of contents and figures, as well as an index based on keywords and vocabulary terms.

Students

To access courses, students use our Roadmap navigational software. The Roadmap queries the repository for a list of available courses (stored as RDF) and presents this list to the student. The student then selects his or her course, and the roadmap downloads the corresponding course description file. Once the file is downloaded, the Roadmap presents the student with an outline of the course (See the left hand side of Fig. 3) and the set of imposed links for the current module (Right hand side of Fig. 3.) The course view gives students a high-level view of the course materials, allowing them to track their progress. The link view lets them explore relationships and experience how the materials are related. Students may also choose to gain a different perspective by switching link views from the instructor-imposed links to the auxiliary links provided by the module authors. The Roadmap is currently implemented as a browser add-on using Netscape's eXtensible User-Interface Language (XUL)30 and is only available for Netscape 6 or the Mozilla browser. We are working on a similar plugin for Microsoft's Internet Explorer, but in the meantime the system falls back to generating HTML webpages that achieve a similar effect using frames.

Figure 3 The Connexions Roadmap

With or without the Roadmap, when a student retrieves a module for viewing, XSLT stylesheets transform the content-based XML (CNXML and content MathML) into appropriate presentation dialects (XHTML and Presentation MathML.) The particular stylesheets used are determined by the Connexions server, based on the student's specific browser and the parameters specified by the course instructor (if the student is accessing the module as part of a course.) In this way students see the series of modules as a stylistically coherent text using their instructor's preferred notation. These transformations are largely done server-side, although we are investigating the use of client-side transformations for the future. A notable exception to this is our client-side use of the MathML stylesheet provided by the W3C MathML working group21, enabling the same source to be used by different rendering environments. This allows the same module to be viewed by browsers with a wide range of functionality. We currently support Mozilla with built-in MathML support and Internet Explorer 6 with Design Science's MathPlayer plugin13 (Internet Explorer 5.5 is also supported with an upgrade to to version 3 or greater of Microsoft's MSXML parser.) In the future we hope to support other browsers by providing a transformation to bare-bones HTML with images for the math.