Revision: 1833 1

jMKT: Java MaketestMaster's Project Report

Matthew Healy <mjh@cs.rit.edu>Copyright © 2005-2006 Matthew J. Healy

Abstract

A common task confronting instructors is that of assembling exams and quizzes to assist in evalu-ating their students' comprehension of course material. As a result, instructors often build up col-lections of questions that can be reused across multiple sessions of a course, so that they do notneed to create a new examination from scratch every time that one is required. These collectionsmay be scattered across multiple documents (either electronic or printed), and assembling new ex-ams from existing content can be a time-consuming process.

A primary goal of this project was to produce a set of applications that allow an instructor to inter-actively construct tests or quizzes (and accompanying answer keys) from previously created setsof items, using a combination of Java and XML-based tools. These applications allow for futureenhancements, while providing a compelling alternative to tools such as "Maketest" ("MKT") andvarious commercial offerings.

Some additional goals of this project include providing cross-platform support for the system (ini-tially targeting the Solaris1, Microsoft Windows2, Apple Macintosh OS X3, and Linux4 operatingsystems), and addressing some "ease of use" issues for individuals from outside of the computerscience arena.

1 Solaris® is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.2 Microsoft® and Windows® are either trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries.3 Apple®, Macintosh®, and OS X® are either trademarks or registered trademarks of Apple Computer, Inc. in the United States and/or other countries.4 Linux® is a trademark or registered trademark of Linus Torvalds in the United States and other countries.

jMKT: Java Maketest

Revision: 1833 2

Table of Contents1. Introduction ................................................................................................................................... 42. Overview of project area .................................................................................................................. 5

2.1. Predecessor tool ................................................................................................................... 52.2. Some MKT alternatives ........................................................................................................ 9

3. Description of program functionality ................................................................................................ 113.1. Content generation .............................................................................................................. 113.2. Exam generation ................................................................................................................. 123.3. MKT content conversion ..................................................................................................... 13

4. Outline of core technologies employed .............................................................................................. 144.1. Java .................................................................................................................................. 144.2. XML ................................................................................................................................ 144.3. XSL-FO ............................................................................................................................ 144.4. XSLT ............................................................................................................................... 144.5. XML Schema .................................................................................................................... 154.6. Scripting tools .................................................................................................................... 154.7. JDOM .............................................................................................................................. 154.8. FOP ................................................................................................................................. 16

5. Overview of main modules ............................................................................................................. 175.1. Core interfaces ................................................................................................................... 175.2. Data management ............................................................................................................... 185.3. User interface .................................................................................................................... 185.4. Output generation ............................................................................................................... 195.5. XML Schema files .............................................................................................................. 205.6. XML stylesheets ................................................................................................................. 215.7. Conversion utilities ............................................................................................................. 22

6. Problems encountered during development ........................................................................................ 246.1. Platform-specific UI requirements .......................................................................................... 246.2. MKT content conversion issues ............................................................................................ 256.3. Resource input streams ........................................................................................................ 266.4. FOP-related issues .............................................................................................................. 26

7. Possible extension points and known limitations ................................................................................. 278. Conclusion ................................................................................................................................... 29A. Definitions and acronyms .............................................................................................................. 30B. UML diagrams ............................................................................................................................. 32

B.1. Core interfaces .................................................................................................................. 32B.2. jMKT type implementations ................................................................................................ 33

C. Screenshots .................................................................................................................................. 37C.1. Question editors ................................................................................................................. 37C.2. Exam editing ..................................................................................................................... 42C.3. Miscellaneous .................................................................................................................... 44

D. Sample documents ........................................................................................................................ 45D.1. Content items (questions) .................................................................................................... 45D.2. Exam document ................................................................................................................. 51D.3. jMKT configuration file ..................................................................................................... 56

Bibliography .................................................................................................................................... 58

jMKT: Java Maketest

Revision: 1833 3

DedicationI would like to offer my sincere thanks to Dr. James Heliotis, Warren Carithers, and Sidney Marshall for their willing-ness to serve on my committee, as well as to Ken Reek, both for his work on the MKT application (which has servedme well in the past), and for his help in identifying some hidden weaknesses (and strengths!) in MKT as I approachedthis project. Thanks also to Joyce Nagle and Kay Drury for their help in shaping the course of the project.

Most of all, I would like to thank Emily, Ray, and Scott, without whose support I never would have been able to dothis. Thanks for the hugs and the smiles, guys!

jMKT: Java Maketest

Revision: 1833 4

1. IntroductionA common problem confronting instructors (including myself) is that of assembling exams and quizzes to assist inevaluating their students' comprehension of course material. As a result, instructors often build up collections of ques-tions that can be reused across multiple sessions of a course, so that they do not need to create a new examinationfrom scratch every time that one is required. These collections may be scattered across multiple documents (eitherelectronic or printed), and assembling new exams from existing content can be a time-consuming process.

The purpose of the project described by this report was to develop a set of (primarily Java-based) applications –collectively referred to as "Java Maketest" or jMKT – that will assist in the exam generation process.

A portion of the requirements definition work for jMKT included a review of some existing alternatives, with a par-ticular focus on an existing tool in use by the CS department at RIT. Other requirements were derived from discussionswith faculty members at both RIT and several local public high schools.

The primary functional goals for the project included:

• Providing a "rich" user interface, allowing easy evaluation of exam item content.

• Minimizing the dependencies on external tools for driving the generation of actual printable exam documents.

• Cross-platform functionality, with jMKT 1.0 supporting several popular operating system environments.5

• Providing an extensible base for future development, in terms of both the type of exam content supported and theunderlying functionality provided by the tools.

jMKT: Java Maketest

Revision: 1833 5

2. Overview of project area

2.1. Predecessor tool

The "Maketest" (MKT) application is a program created by Professor Kenneth Reek that allows an instructor tointeractively construct tests and quizzes from a previously created pool of items, with the items typically stored asseparate files in a hierarchical directory structure that reflects their content. [Reek92] The program supports five coretypes of questions: multiple-choice, matching, true/false, fill-in-the-blank and essay.

MKT can produce exam documents and answer keys in a form suitable for formatting with troff[troff.org] and the -me[Allman] macros, and can support the use of content from additional troff-friendly tools being embedded in items(e.g., fig, eqn, etc.), or of other troff macro sets, including some created by Prof. Reek as a part of the core application.6

Creating slightly different versions of the same examination is simple, as the program supports basic operations forrandomizing the order in which the questions and answers appear in each version.

Usage basics

MKT is primarily used in two modes: item selection and test editing.

When operating in item selection mode, the user uses MKT to navigate through a hierarchy of folders that containitems being considered for addition to the current exam document. The items within each folder are listed within theapplication, and the troff-based content of an individual question can be previewed from within the program, onescreenful at a time.7 As the instructor identifies questions to be included in the exam, they issue commands to "additem #N" to the current test, which causes the program to append the question to end of the current exam document.MKT indicates which items have been added to the test by replacing the ":" after their number in the directory listingwith a "U"; when looking at the listing of a "parent" directory. A similar mechanism is used to indicate which sub-directories contain one or more items that have already been added to the exam.

Figure 1. MKT item-selection mode

6 Support for fig in MKT is actually provided by lwroff, a custom program prepared by Prof. Reek.7 The standard UNIX command more is used for pagination support.

jMKT: Java Maketest

Revision: 1833 6

Figure 2. MKT item-selection mode (item previewing)

The test editing mode allows an instructor to modify an exam or its contents at the question level. When operating inthis mode, an instructor can enter textual commands instructing MKT to:

• Discard an item that was previously added to the current exam document, or all items. (For example, "discard5" will delete the fifth item on the exam.)

• Change the ordering of the items in the exam, either by moving an item to a specific location (e.g., "move item #10before item #5"), or by telling MKT to randomize the ordering of test items (other than header/trailer items).8

• Re-read a particular item's content from its original file on the disk. (This is typically used if the item file has beenedited after being added to the exam document, such as if an error was discoved in the item's content or answer.)

• Change the number of points associated with a particular item on the test.

• Insert page breaks between specific items, in order to improve the flow of the exam (e.g., "start a new page afteritem #8").

jMKT: Java Maketest

Revision: 1833 7

Figure 3. MKT test editing mode

Limitations

While MKT has been used successfully in RIT's Computer Science department (and elsewhere), there are some sig-nificant limitations on its portability to other systems, and to its accessibility by less-experienced groups of users.

• At present, only a curses-based (full-screen text) UI for the program exists. While this simplifies the demandsimposed on user hardware (e.g., it can be used by a user remotely logged in via a dial-up connection on a VT-100terminal as easily as it can by a user sitting at the console of a high-end multi-processor Sun workstation), the "userexperience" does not rise to the level of expectations held by most individuals, who have grown accustomed tographical user interfaces to applications.

• While the creation of basic test items does not require a knowledge of troff, more sophisticated ("rich") content cre-ation is difficult (if not impossible) to perform without some experience with this and related tools. Such experienceis still fairly common within the Computer Science community, but it is becoming less so as students and facultymembers frequently turn to other "rich editors", such as Microsoft Office, Open Office, and other GUI-based tools.In addition, experience with troff is largely non-existent within many other groups where a tool such as MKT mightprove to be extremely valuable (such as teachers in other disciplines or in primary/secondary schools), substantiallyreducing its accessibility to these potential users.

• While the reliance of MKT on external tools like troff for rendering exam documents for printing greatly simplifiesits internal complexity, it also limits its portability. Though the program could be ported to a new platform that didnot support troff, its functionality would be limited to simply creating exam documents that would then need to betransported to another system for rendering to a printer.

• MKT does not provide embedded support for previewing an exam's final (printed) form. While this limitation canbe partially overcome by generating a PostScript version of the exam using troff, and then previewing the PostScriptcontent with an external tool (e.g., ghostview), this introduces additional external dependencies on the system asa whole, and is somewhat time-consuming.

In addition, while this alternative approach can be used for examinations as a whole, it is ill-suited to previewingindividual items that contain embedded images, etc., unless they are first added to an exam document so that theymay be previewed as a part of the whole. If the user's intention is simply to evaluate the suitability of the item forinclusion in the examination, this requires repeatedly adding a question, generating a PostScript version of the exam,previewing it under an external tool, and removing the question if it does not meet the user's needs, before goingon to the next question being considered.

jMKT: Java Maketest

Revision: 1833 8

• The output formats supported by MKT are largely restricted to those supported by troff (or PostScript, via Prof.Reek's lwroff), which limits the ability of the user to view/print the material, or to provide access to it through othermeans, as well as limiting the portability of the application to other platforms that do not provide support for thismechanism.

• MKT's extensibility for new item (question) or test formats is somewhat limited. Adding new item formats requiresmodifying the program's code to support the parsing of new file structures, while the overall exam format is drivenby a combination of the internal logic of the program and any troff-based content that is embedded into the itemsbeing added to an exam. Additionally, the mixture of explicit "rendering intent" information with item informationreduces the ability of exam content to be "repurposed" for additional formats.

• Under MKT, the logical organization of a pool of test items must be physically expressed in terms of its structure ona disk. There is no way of indicating to the application what concepts are covered by an item from within its content,and it is the responsibility of the user to peruse each directory separately, due to the nature of the user interface.

As a result, if a question applies to several different concept areas (e.g., a question that covered "exception-handling","I/O in Java", and algorithm complexity), it must either be:

• copied into multiple directories that are each dedicated to a particular type of problem (e.g., "CS2/Exceptions","CS2/IO", and "CS2/Complexity"), which increases the risk of issues such as errors in a question not beingcorrected across all copies,

• placed in a special directory that indicates its full coverage, leading to a host of separate directories, each of whichwould contain a small number of items and must be examined separately by the user, or

• placed in a single directory, and then "linked to" within the file system from all appropriate locations by the user;if the question's content is modified (either enhanced or simplified) so that the concept set covered changes, theselinks could become obsolete, diminishing the user experience.

• MKT provides little in the way of "online help" functionality, and is largely restricted to providing textual summariesof the command words and phrases understood by the program. For more detailed information, the user must eitherobtain and peruse a copy of the user's guide for the application, or else must seek out others in the community thathave greater experience with the program.

It was my intention to address many of these limitations in jMKT 1.0.

jMKT: Java Maketest

Revision: 1833 9

2.2. Some MKT alternativesWhile preparing to work on this project, I also reviewed some of the commercially-available alternatives to MKT. Inparticular, I looked at the following applications:

Table 1. Commercial alternatives to MKT

Product name Maker Platforms Pricing†

Windows $49.95Diploma Brownstone

MacOS Classic $39.95

ExamView Test Generator ExamView MS Windows/Mac OS X $99.00

MicroTest III Chariot Software Group MS Windows/MacOS Classic/Mac OS X $159.00

Random Test Generator PRO Hirtle Software MS Windows $99.95

Test Generator Fain & Company MS Windows $79.00† Pricing information is on a single-license basis. For many of the applications evaluated, discounts are provided when purchasing in larger quantities.

These applications are typically priced on a per-machine basis, and support a limited number of platforms: both of thesefactors can reduce their viability for some target audiences. In addition, many of them are geared towards computerizedtesting, either through an online mechanism (where the students can access the test via a Web browser or some otherclient application), or as a "self-proctored" exam that must be taken on an appropriately equipped PC, rather thantowards "traditional" testing.

The following features were common among most/all of these applications, and are also present in jMKT 1.0.

• The ability to create a wide range of exam questions, including those forms supported by MKT.

• Support for embedding images within a test question.

• Support for multiple output formats (typically at least as RTF and text output).

• Randomization of test items on an exam.

• Creation of an unlimited number of test banks, and population of individual test banks with an unlimited numberof questions.

• Saving tests to files for re-use at any time in the future.

• Importing of existing exam question content into the format used by the application.

• Random selection of test items. (In some applications, this extends to the random generation of an entire test, basedon an instructor's specification of the number of questions to draw from each topic area.)

These applications also frequently provided support for "enhanced usage" that are not present in jMKT 1.0. Somenotable options include:

• Generation of test item content within the primary application, typically using an interface similar to that of atraditional word processing package.

• Spell checking and/or thesaurus capabilities.

• Support for equation editing using embedded tools.

• Support for online presentation of the tests, either through a hosted web service provided by the vendor, or byexporting the tests to environments like Blackboard or WebCT.

jMKT: Java Maketest

Revision: 1833 10

• Course list and/or gradebook management functionality.

• Password protection of test banks and exams.

• Support for generating surveys, which often feature different types of questions than are normally seen on traditionalexams.

The lack of these "enhanced usage" features does not appear to present significant limits on how jMKT may be used. Inaddition, jMKT has been designed for future extensibility, allowing these features to be added at a later date if desired.

jMKT: Java Maketest

Revision: 1833 11

3. Description of program functionalityWhen jMKT is started by "double-clicking" on the JAR file from within a GUI environment (e.g., Windows Explorer,Mac OS Finder, etc.), it will present the user with a dialog (the "gallery") providing simple access to a list of optionsfor initial use. Alternatively, if jMKT is started from the command line, the user may choose to specify the paths tosome files (exams and/or content items) to be opened for use.

The jMKT application provides three main types of functionality:

• Content (question) generation and editing

• Exam generation, editing, and printing

• MKT content conversion

3.1. Content generationjMKT content can be created in several ways:

• Basic content (i.e., content that does not include formatting instructions, such as bold fonts, tables, etc.) may becreated using content editor applets that are included in the jMKT distribution.9 A different editor is used for eachtype of content, allowing the user to ignore the task of explicitly defining the XML "meta-information" that indicatesthe various portions of the content (e.g., background text, instructor's notes, etc.).10

The editor applets support both the creation of new content from templates provided with the jMKT distribution (orcreated by the user), as well as modification of existing content items. However, it is important to note that if a filecontaining more sophisticated content formatting is opened within one of the editor applets, the formatting contentwill be stripped out of the presentation within the applet, and will be lost when the file is resaved.

• More sophisticated content may be created manually using a text editor to prepare/modify content items. This ap-proach allows the user to take full advantage of the support for various formatting options in content files, but itassumes a certain degree of comfort in working with XML data.

Although the jMKT application is able to handle some content containing minor XML validation errors, moresignificant errors (or data that is not well-formed XML) may cause the content to be ignored by the application.As a result, when content is prepared/modified manually, users should take care to use an editor that is capable ofperforming validation of the material against the XML Schema for jMKT, or else to validate the content manuallyafterward using tools such as xmllint.

Regardless of the means by which content is prepared, it may also include meta-data defining characteristics such asthe author(s), a brief (normally 1-line) summary of the item, a list of the concepts covered by the question, etc.

jMKT: Java Maketest

Revision: 1833 12

3.2. Exam generationThe main jMKT application may be used to perform a number of operations involved with generating exam docu-ments:

• Item pools may be opened in order to provide a collection of content to be considered for use on the exam. (Theymay also be reloaded, if changed externally, or closed if they are no longer needed.)

• Items may be selected by the user from the item pools that have been opened, or jMKT may randomly select itemsfor addition. During the process of selecting items for the test, the user may open an HTML-based preview of theitem, which will display the question's content, the correct answer (if any), and any "instructor's notes" that havebeen added to the item for use in grading purposes, etc.

The user may also insert "hard" page breaks into the exam, if desired, in order to change the pagination of the examwhen printed.

• jMKT can randomize the order of the items on an exam, or the order of answers given for multiple-choice andsimilar types of content, so that different versions of the same exam may be created for different sections of a course,or for different groups of students within a single section. (In order to aid in the generation of safe tests with a fairdegree of uniqueness, jMKT also randomizes the order of answers when the exam document is saved, as did MKT.)

The order of the items on an exam may also be changed by the user by performing "drag-and-drop" operations onthe list of items that have been added to the exam.

• The user may change various "properties" associated with an exam, such as the instructor's name, course title, examduration, etc. The user-specific default properties that will be used in generating a new exam may also be changedvia the application's preferences.

• The exam may be previewed in several ways:

• HTML-based versions of the exam are available within the main application window, providing a means ofquickly reviewing the test to be given to students, the answer key, or an "annotated" exam with both the questionsand answers. These views of the exam are "live", in that they are updated as questions are added to/removedfrom the exam document, or when the order of the questions is changed, as well as when the exam's "properties"are changed.

The primary limitation to these views of the exam is that the "live" aspect of the preview comes at the cost ofproviding a page-ready view of the exam. (For example, there is no way to identify where page breaks willbe inserted into the exam when it is printed or exported in a printable format, although "hard" page breaks areindicated via horizontal lines in the preview.)

• A "print preview" of the three versions of the exam (test, key, annotated test) is also available. In this mode, apreview of the exam as it will appear when printed is prepared and displayed to the user. The user may reviewthe content on a page-by-page basis, zoom in or out on different sections, etc.

• A report on the "content coverage" provided by the exam may also be generated from the exam document. Thisview of the exam provides a list of the concepts covered by the questions on the exam, and the total number ofpoints for the questions associated with each of the concepts.

• The exam document can be saved and reloaded, allowing the process of creating an exam to take place over anynumber of sessions.

• The exam document may be printed, either as an exam to be given to students, an answer key, or an annotatedexam (e.g., for use in a review session). It may also be exported in a number of printable formats, including AdobePortable Document Format (PDF), Postscript (PS), and HP Printer Control Language (PCL).

jMKT: Java Maketest

Revision: 1833 13

The general progression of preparing an exam under jMKT is outlined in Figure 4, “jMKT exam preparation flow”,below:

Figure 4. jMKT exam preparation flow

3.3. MKT content conversionMKT is an application originally created by Professor Kenneth Reek, and used in a number of courses offered byRIT's Computer Science department. As one of the goals of this project was to provide a compelling alternative toMKT, support for converting existing content used in those courses was considered to be an important factor in gainingacceptance of the new tool.

Included within the jMKT application set is a conversion script (mkt2jmkt.sh) that uses a mixture of awk, sed, andBourne-shell scripting to convert MKT content into the format used by jMKT. This tool has been used to performthe "bulk" translation of questions from MKT to jMKT formats for both CS3 and CS4 courses at RIT, which weresubsequently used on exams during the Fall and Winter quarters of the 2005-2006 school year.

This script is intended to be executed from the command-line under UNIX11, and will translate MKT content filesspecified as parameters. The resulting jMKT content is stored in files with the same name as the original file, with.xml added as a extension to the file name.

For example, the following command translates the files q1 and q2 (in the current directory) into q1.xml andq2.xml:

% mkt2jmkt.sh q1 q2

q1 is a text-only itemRunning 'ContentFixup' against 'q1.xml'....

q2 is a multiple-choice questionRunning 'ContentFixup' against 'q2.xml'....

11 UNIX is a registered trademark of The Open Group.

jMKT: Java Maketest

Revision: 1833 14

4. Outline of core technologies employed

4.1. JavaJava is both a programming language and a platform. Applications written in the Java programming language arecompiled into a platform-neutral set of instructions, referred to as "Java bytecode", which is then executed by a JavaVirtual Machine ("JVM"), which translates the instructions into a form that is understood by the specific machine onwhich the application is being used. As a result, Java provides developers with the ability to write software that can beexecuted on many platforms without any changes, in accordance with Sun's slogan, "Write once, run everywhere."12

Java provides support for a number of functions that are used within the jMKT application, including file I/O, graphicaluser interface (GUI) support, reflection/introspection, and XML parsing. While each of these needs could have beenprovided by various libraries available under other programming languages that would generate platform-specific code(such as C++), the use of Java allowed the jMKT application to be easily carried to any platform on which a JVM isavailable, thus fulfilling the goal of cross-platform usability.

4.2. XMLXML (the Extensible Markup Language) is a standard mechanism for document markup that has been endorsed by theWorld Wide Web Consortium (W3C), and defines a generic syntax used to mark up data with simple, human-readabletags in order to provide a standard format for computer documents [Yergeau04]. Data is included in XML documentsas strings of text, and is surrounded by text markup that describes the data.

XML's basic unit of data and markup is called an element. The XML specification defines the exact syntax this markupmust follow (e.g., how elements are delimited by tags, what a tag looks like, what names are acceptable for elements,where attributes are placed, etc.). XML syntax can be further refined for specific application domains, allowing thedefinition of "dialects" appropriate to a particular problem domain.

XML data is used in a variety of forms within the jMKT application: a custom dialect of XML is used as the basicmechanism for providing information about both formatting intentions of item content (e.g., "emphasis", "underline",etc.) and meta-information describing the nature of the material (e.g., the number of points associated with a question,the concepts it addresses, etc.). Additional XML-based technologies are used to validate the format and content of newitems created by instructors, and to generate printable versions of exams.

4.3. XSL-FOXSL-FO ("XML Stylesheet Language Formatting Objects") is one of two technologies that are collectively referredto as "the XSL Standard". [Pawson02, Adler01] XSL-FO is an XML-based language for describing the formatting ofdata for output to screen, paper or other media. XSL-FO allows a user (or a program) to define the size and orientationof media to be printed (e.g., "8.5x11 inch paper, in portrait mode"), the characteristics of text (e.g., bolding, sizing,fonts, etc.), and so on.

Within the scope of this project, XSL-FO data is generated as an internal representation of an exam or exam key fromthe items in an exam document. This intermediate form is then translated into the targeted output format (PDF, etc.)or rendered in the UI (for "rich previewing").

4.4. XSLTXSLT ("XML Stylesheet Language Transformations") is the second half of the XSL Standard. [Clark99] This type ofXSL allows the user to describe the process by which data in one XML document is to be used to generate another

12 This slogan is not completely accurate, as there are sometimes differences between the implementation of the Java platform for one hardware platform/operating system and another. As a result,it is sometimes parodied as "Write once, test everywhere." While this fact cannot be ignored, it did not provide significant issues for this project.

jMKT: Java Maketest

Revision: 1833 15

XML document, or some other type of document that is of interest, such as HTML or a "simple text" file. XSLT canadd new elements into the output file, or remove elements. It can rearrange and sort elements, test and make decisionsabout which elements are to display, as well as other transformations.

Within the scope of this project, XSLT is used to transform test item content into an intermediate XSL-FO data formthat is then used to generate the final document for printing, etc. It is also used to transform test item content intoHTML for "rapid previewing" within the jMKT application.

4.5. XML SchemaXML Schema is an additional XML technology that can be used to describe the required structure of an XML doc-ument. [Biron04, Fallside04, Thompson04] This allows the content of the document to be validated, in order to en-sure that the rules governing its preparation have been preserved. It can also be used to provide default values forvarious pieces of information (e.g., points associated with a given item) if the information is not specified in the XMLdocument.

Within the scope of this project, XML Schema is used to provide definitions for the structure of the XML contentbeing manipulated at level of both individual items and full exam documents. This allows for the validation of contentcreated "by hand" in a text editor by knowledgeable users, as well as for verification that existing MKT content istransformed into valid jMKT content.

4.6. Scripting toolsGiven the comparatively "free-form" nature of MKT item formatting, I elected to treat the bulk of the work involvedwith translating MKT content into the jMKT format as a simple problem in text processing to be solved with shellscripting tools, rather than by writing a more sophisticated parsing tool.

The conversion script uses a number of traditional UNIX tools for its work, including awk, sed, and grep. While oneof the goals of the project was to provide platform-neutral functionality (chiefly through the use of Java-based tools),the fact that MKT is effectively a UNIX-based application means that any existing content that is to be converted tothe jMKT format is likely to be in an environment where UNIX tools are available. As a result, the limited dependenceon UNIX tools that this decision introduced represents a reasonably minor issue.13

4.7. JDOMJDOM provides a way to represent an XML document for easy and efficient reading, manipulation, and writing in aJava program. It provides a lightweight and fast alternative to the standard XML Document Object Model (DOM) orthe Simple API for XML (SAX), as it is optimized for use by Java programmers.

The JDOM framework is used by the jMKT application suite to provide a means of accessing and manipulating theXML data for content items while it is loaded into the program's memory. A copy of the JDOM framework is includedwithin the jMKT JAR file, allowing it to be used by within the tools without needing to install it separately.

13 In addition, the UNIX tools being used have been ported to a number of other platforms (e.g., to Windows under the Cygwin project), and thus if the conversion script needs to be run on non-UNIX systems, this will frequently be possible.

jMKT: Java Maketest

Revision: 1833 16

4.8. FOPFOP (Formatting Objects Processor) is a print formatter for XSL-FO being developed in Java as an open-source projectby the Apache Software Foundation, providing both a stand-alone program and a library supporting the render anXML file containing XSL-FO data into a page layout. The primary output format supported by FOP is PDF, but otherformats are supported, including PCL, AWT (GUI previewing), and direct printing.

The FOP library is used by the jMKT application suite to provide a means of printing exam documents, and to exportthem in a variety of formats. In addition, the AWT renderer component within the FOP library is used to provide page-ready previewing of exam content. A copy of the FOP library is included within the jMKT JAR file, allowing it tobe used by within the tools without needing to install it separately.

jMKT: Java Maketest

Revision: 1833 17

5. Overview of main modulesThe classes written for use in this project are divided into the following packages within the edu.rit.cs namespace:

Table 2. Java class packages

Package name Purpose

jmktContains core interfaces for the jMKT data types (exams, content items), and im-plementations of these interfaces.

jmkt.util Contains utility classes for working with jMKT data types.

maketestContains user interface components for the jMKT application suite, including themain application class (JMaketest).

maketest.editors Contains simple GUI-based editors for the jMKT question types.

mjh.utilContains various utility classes, including reusable GUI "widget" classes, localiza-tion support, etc.

mjh.util.platformContains support for platform-specific functionality (e.g., managing differences inprogram user interfaces based on the standards for a given operating system).

mjh.util.rsrcContains classes supporting a custom URL protocol ("rsrc:") used to deal withdata packaged as resources for a Java application.

mjh.xml Contains various classes providing XML manipulation support.

mjh.xml.exportContains classes supporting the export of XML data in a variety of formats, usingthe Apache FOP library.

Unified Modeling Language (UML) diagrams outlining many of the classes contained within these packages, as wellas some of the relationships between them, may be found in Appendix B, UML diagrams.

5.1. Core interfacesThe primary interfaces defined in the edu.rit.cs.jmkt package for working with jMKT data include Exam(which provides for management of an exam document), and Content (which provides the basic definition of contentitems that can be used within an exam document).

The Content interface is further specialized in order to define the following types of material:

• Headers, which may be either information displayed at the top of each page (e.g., a space for the student's name,or the title of the test), or content that is displayed on the first page of the exam (e.g., directions).

• Trailers, which may be either information displayed at the bottom of each page (e.g., page numbers), or contentthat is displayed on the last page of the exam (e.g., an honor code to be signed by the student).

• Items, which provide "normal" test content (i.e., questions, background text/images, etc.).

jMKT: Java Maketest

Revision: 1833 18

5.2. Data managementThe edu.rit.cs.jmkt package includes direct implementations of both the Exam and Content interfaces, al-lowing objects to be loaded from XML data via disk files or InputStreams.

The Exam interface is implemented by the BasicExam class, while the jMKT content types are supported by avariety of classes, outlined in Table 3, “Content type implementations”, below. The mapping of a given jMKT contenttype onto a particular type of object used to manage its data is determined at run-time via information provided inan XML-based configuration file. This configuration file defines mappings from the "base" element name used for agiven content item onto custom classes, editors, stylesheets, and templates used for content of that type. (An exampleof this configuration file may be found in Section D.3, “jMKT configuration file”.14)

Table 3. Content type implementations

Interface Implementing class Purpose

Item BasicItemA generic implementation for jMKT question data. (This is suf-ficient for handling of text-only content, but is specialized in or-der to provide handling of actual question items.)

Item EssayItem Used to handle essay questions.

Item TFItem Used to handle true/false questions.

Item MatchingItem Used to handle "matching" questions.

Item MultipleGuessItem Used to handle multiple-choice questions.

Item MultipleAnswerItemUsed to handle "multiple-answer" questions (i.e., "pick all cor-rect answers from the following list").

Header BasicHeader Used to handle header content items.

Trailer BasicTrailer Used to handle trailer content items.

5.3. User interfaceThe edu.rit.cs.maketest package provides the main user interface for the jMKT application suite, includingthe exam editing and preview windows, preference dialogs, "gallery" screen, etc. Although the application is currentlytargeting only English-speaking users, it is designed for extensibility to other languages through the use of resourcefiles that provide mappings for well-defined strings into localized values.

Table 4. Major jMKT application GUI classes

Class Purpose

ApplicationInterface defining access to the core functionality provided by the jMKT main appli-cation. This interface is defined so that a "stubbed" version of the application may bedefined for unit testing various components of the system.

DisplayWindowBase class for child windows displayed within an exam document window (e.g., "fastpreviews" of the exam/key or of items being considered for inclusion on the exam, etc.).

ExamContentListCustom list control used to display the items currently in use on the exam, as well asto re-order/edit them.

GalleryDialog presented to the user when jMKT is invoked without parameters (or when acti-vated via the "File" menu), granting access to creating/editing exams or content items.

14 An initial version of this file is included in the "stock" jMKT release, and is copied into a user-specific directory when the application is launched for the first time, in order to allow customizedstylesheets and handlers to be used.

jMKT: Java Maketest

Revision: 1833 19

Class Purpose

ItemListPaneCustom tree view control used to display the contents of the item pools that have beenopened for use in constructing the test, as well as to show the concepts and items thathave been selected for use.

JMaketest The main class for the jMKT application.

MainWindow The primary window used in editing exams.

PropertiesDialogDialog used to display and edit the settings used on an exam (e.g., instructor's name,base font characteristics, etc.), as well as the default settings used to create new exams.

This module also includes a sub-package (edu.rit.cs.maketest.editor) allowing the five types of questions(and "text-only" items) supported in jMKT 1.0, to be edited. In addition, some components are provided to supportthe development of applets to support the editing of other question types added in future versions.

Table 5. Major jMKT item editor GUI classes

Class Purpose

EditorDefines a common interface for GUI "widgets" that allow content items tobe edited.

PanelBasedEditor

Provides a reusable base class for "widgets" that support the editing of varioustypes of content items. This class implements portions of the Editor inter-face, while leaving others to be implemented by classes that can handle thespecific details of a given type of content.

This class is derived from JPanel, and thus needs to be embedded within atop-level window in order to be used.

BasicEditorHostA JFrame-based class, capable of hosting a content item editor and providingbasic supporting UI controls (e.g., a "File" menu, etc.).

StockItemContentPanelA sub-panel for use within content item editors, providing access to data that isconsistent across all content item types (e.g., list of authors, concepts coveredby the item, summary, etc.).

ContentChangeEvent

An event generated when a content item has been changed within a con-tent item editor, which will be delivered to objects that implement the Con-tentChangeListener interface and have registered for notifications withthe editor.

EditorFactory

Defines a factory object, which can create an Editor for a given contentitem. The editor objects are created using the Java Reflection API, with theunderlying object type being determined from mappings defined in the appli-cation configuration file from content item types to Java classes.

In jMKT 1.0, editors are provided for the five types of questions supportedby the application, as well as for simple "text-only" items.

5.4. Output generation

The edu.rit.cs.mjh.xml.export package provides support for transforming XML data into a variety of for-mats (including PDF, PCL, and PostScript) through the use of a caller-specified XML stylesheet that defines trans-formations from the source XML content into XSL-FO as an intermediate step. The classes in the package followthe "Strategy" design pattern, where an abstract base class (Converter) defines a common interface to the variousconversion algorithms, which are then implemented within derived classes: the user of the package picks a particular

jMKT: Java Maketest

Revision: 1833 20

implementation of the strategy (i.e., a specific output format), instantiates an object that provides that implementation,and then proceeds to work with the generic interface.

Table 6. XML export classes

Class name Output format

ConverterAn abstract class defining the common interface to the XML data converter implementa-tions.

FOConverterAllows XML data to be exported as XSL-FO content. (This is the intermediate formatused for most of the other conversions, but is also a useful format in its own right, as it isdirectly supported by some text editing tools.)

MIFConverter(Experimental) Allows XML data to be exported as Maker Interchange Format(FrameMaker) content.

PCLConverterAllows XML data to be exported in Hewlett-Packard's Printer Control Language (PCL)format.

PDFConverter Allows XML data to be exported in Adobe's Portable Document Format (PDF).

PSConverter Allows XML data to be exported as Postscript (PS) content.

SVGConverter(Experimental) Allows XML data to be exported as Scalable Vector Graphics (SVG) con-tent.

TextConverter

Allows XML data to be exported in a "plain text" format that attempts to match of theFOP PDFRenderer as closely as possible. (Note: the FOP renderer for this format isvery limited, as it was originally developed to accommodate an system that could onlyaccept plain text files, and is typically used in FOP solely for getting a rough/rapid viewof a document's text.)

5.5. XML Schema files

XML Schema definitions are provided for all of the types of XML data that can be generated/used within the applica-tion, allowing this information to be validated after manual creation/editing. (These are also used by the conversionutilities to validate jMKT files generated from existing MKT content.)

As is common with many XML Schema definitions, the jMKT definitions are modular, allowing more complex XMLdefinitions (e.g., exams) to be created with simpler ones (e.g., specific content item types) used as building blocks.This also has the advantage of allowing any type of jMKT content to be validated using a single schema definitionfile, rather than requiring that the user reference a definition file that is specific to its content.

An additional schema file is provided for the jMKT configuration file, used to map content item types to the XMLstylesheets, editor applets, and support classes that are used to interact with them.

Table 7. XML Schema files

File name Purpose

JMaketest-1.0.xsdThe primary XML Schema definition for jMKT content, including all content itemsand exam documents.

ExamCore.xsdDefines the internal XML structure of a jMKT exam, as a collection of propertysettings and content items.

ItemGenerics.xsdDefines some generic XML structures and reusable elements shared across manytypes of jMKT content.

jMKT: Java Maketest

Revision: 1833 21

File name Purpose

examHead-er-header.xsd

Defines the structure of "examHeader" content items (a form of header content usedto provide the standard heading across pages of exams given in RIT's ComputerScience department).

essay-questions.xsd Defines the structure of jMKT essay question content items.

ma-questions.xsd Defines the structure of jMKT "multiple-answer" question content items.

match-questions.xsd Defines the structure of jMKT "matching" question content items.

mc-questions.xsd Defines the structure of jMKT "multiple-choice" question content items.

text-item.xsd Defines the structure of jMKT text-only content items.

tf-question.xsd Defines the structure of jMKT "true/false" question content items.

jmktSettings.xsd Defines the structure of jMKT configuration files.

5.6. XML stylesheetsA large number of stylesheets had to be defined for use in jMKT. Two stylesheets were prepared for each of the contentitem types supported by the system, with one supporting conversion to HTML (for rapid previewing) and the othersupporting conversion to XSL-FO (for export/printing/detailed preview). In addition, a number of other stylesheetswere used to isolate common functionality and/or "macro-level" transformations (e.g., definition of document/pagecharacteristics for XSL-FO, "concept coverage" report generation, etc.).

Table 8. XML stylesheet files

File name Purpose

ExamCore-fo.xsl, ExamCore-html.xslCore ("top-level") stylesheet for rendering of exam documentsinto XSL-FO and HTML.

ItemCore-fo.xsl, ItemCore-html.xslDefines transformations for generic headers, trailers, and items,as well as some common components found in multiple contentitem types (e.g., instructor's notes, authors, etc.).

cs-stock-instructions-fo.xsl, cs-stock-instructions-html.xsl

Defines transformations for "stock" exam instructions, present-ed on the first page of exams given in RIT's Computer Sciencedepartment. (This may be taken as an example for generation ofalternate instruction formats.)

essay-questions-fo.xsl, essay-ques-tions-html.xsl

Defines transformations used to convert essay question contentinto XSL-FO and HTML.

exam-header-fo.xsl, exam-head-er-html.xsl

Defines transformations for examHeader elements, which arerendered as the standard "per-page" header content on RIT CSdepartment exams (i.e., course name, exam type, and exam termspaced throughout the top of each page of the exam).

exam-pageNum-fo.xsl, exam-pa-geNum-html.xsl

Defines transformations for pageNumbering elements, whichare rendered as page numbers at the bottom of each page of theexam.

ma-questions-fo.xsl, ma-ques-tions-html.xsl

Defines transformations used to convert "multiple-answer" ques-tion content into XSL-FO and HTML.

match-questions-fo.xsl, match-ques-tions-html.xsl

Defines transformations used to convert "matching" questioncontent into XSL-FO and HTML.

mc-questions-fo.xsl, mc-ques-tions-html.xsl

Defines transformations used to convert "multiple choice" ques-tion content into XSL-FO and HTML.

jMKT: Java Maketest

Revision: 1833 22

File name Purpose

stock-fop.xsl, stock-html.xslDefines transformations used to convert "stock" formatting in-structions (e.g., bold/italic, lists, etc.) into XSL-FO and HTML.

text-items-fo.xsl, text-items-html.xsl

Defines transformations used to convert "text-only" questioncontent into XSL-FO and HTML.

tf-questions-fop.xsl, tf-ques-tions-html.xsl

Defines transformations used to convert "true/false" questioncontent into XSL-FO and HTML.

pagemaster-fop.xslDefines the framework for page layout in XSL-FO output trans-formations, including page sizing, margins, etc.

ps.xslDefines attribute sets used in numerous XSL-FO transforma-tions.

tables-fo.xslDefines handling of more sophisticated table rendering for XSL-FO output.†

ExamConceptCoverage-html.xslStylesheet used to generate "concept coverage" reports in themain application.

item-support.xslDefines utility transformations used by handlers for specifictypes of content items (e.g., retrieving the number of pointsacross the exam, the total number of scored questions, etc.).

text-manip.xslDefines utility transformations for text processing, such as con-verting strings to upper case, capitalizing the first character in astring, etc.

† Basic tables, using the simple element structure from XHTML, are supported for XSL-FO via transforms defined in stock-fop.xsl. However, these tables are assumed to occupy the entirewidth of the page, with all columns being equally sized, and none of the cells spanning multiple rows/columns.

An alternative approach to using so many stylesheets would have been to collect them into larger stylesheets (e.g., asingle stylesheet handling conversion of all questions to a given format, or handling all conversions for a given typeof question). However, isolating the handling of a given format/content type into separate made the task of debuggingthe stylesheets substantially easier, as well as providing a simple means for end users to define their own customstylesheets for a given content type, or to extend the set of content types without impacting support.

5.7. Conversion utilitiesThe conversion script used to transform MKT content into jMKT materials follows a multiple-phase approach tohandling the procedure. With the exception of the first and last steps in the process (type identification and "fixup"),the changes are applied on a streaming ("pipelined") basis.

1. The MKT file being converted is scanned for specific keywords in order to identify the type of content that itcontains (essay, multiple-choice, matching, true/false, or text-only).

2. Characters that have a specific meaning under XML (e.g., angle-brackets, single- and double-quotes, and amper-sands) are translated into XML entity references.

3. Warnings about unsupported roff content are embedded into the data stream within XML comments.

4. Tabular data is converted from tbl format to the HTML-like syntax used by jMKT content.

5. "Inline" roff formatting instructions (such as bold, italics, etc.) are translated into the jMKT syntax on a line-by-line basis.

6. "Block" roff formatting instructions (such as paragraphs, code listings, bulleted lists, etc.) are translated into jMKTsyntax.

jMKT: Java Maketest

Revision: 1833 23

7. The MKT content markers providing meta-information about the content type, points, and attributes (e.g., answersand distractors on multiple-choice/matching questions, etc.) are migrated to jMKT format.

8. Finally, a small Java application is used to perform "fix-up" operations on the translated content in order to ensurethat it includes a valid content ID and other attributes.15

jMKT: Java Maketest

Revision: 1833 24

6. Problems encountered during developmentProgress on the work for this project was surprisingly smooth, despite the fact that it had key dependencies on a numberof technologies and packages that I had not previously worked with to any significant extent (e.g., JDOM, FOP, XSL-FO, etc.). I believe that this is largely due to the fact that I spent more than six months doing preliminary designs for theproject and researching/prototyping various aspects of it before formally starting work, in addition to the significantexperience I had already developed in using MKT. However, there were several key areas of the project that gaverise to some interesting issues.

6.1. Platform-specific UI requirementsIt is not uncommon for different platforms to impose certain common design constraints on graphical user interfaces(GUIs), including such items as the placement of controls in a dialog, the ordering of items on application menus,etc. In many cases, the constraints on GUIs are similar across many operating systems, reflecting a common base ofuser experience and research into human factors, and thus may be handled within an application without significantconcern. In other cases, the constraints may be dealt with by the Java classes providing support GUI controls (e.g.,selecting an item from a "pop-up" menu on a down-click, vs. on the release of the mouse's button).

However, there are several design considerations imposed under the Apple Macintosh OS X operating system thatwere notably different from those on other platforms being supported by this project, and were not directly providedfor by the Java GUI classes. These included the following:

• The standard ordering of paired buttons such as "OK" and "Cancel" on various dialogs under OS X is reversedfrom that of most other platforms: where most platforms place "OK" to the left and "Cancel" to the right, the OSX platform indicates that an "OK" button should fall to the right.

This issue was handled by the use of a "factory" method that was responsible for generating a JPanel object thatwould contain a pair of "OK" and "Cancel" (or equivalent) buttons, observing the alignment rules and ordering forthe cufrrent platform. Dialogs and other windows that required such a pair of controls could thus delegate the taskof respecting platform norms to the factory method, and focus on higher-level concerns.

• Much as with the placement of standard buttons under OS X, various menu items are also expected to be placeddifferently than under other operating systems. For example, the standard placement of a menu item that will displayinformation about the application is on an application-provided "Help" menu under most other operating systems,but is instead expected to appear only under a special "application menu" on OS X. Similarly, the menu item used toaccess the preferences for an application is typically found under an application-provided "Edit" menu elsewhere,but on OS X this is also expected to fall on the application menu.

This aspect of platform-localization was dealt with through the definition of a custom PlatformMgr class andsome supporting interfaces, which together comprise the edu.rit.cs.mjh.util.platform package. Theseclasses allow an application to ask for the singleton object responsible for providing platform-specific UI manage-ment, such as the integration of specific functionality with a platform-specific UI.

"Handler" interfaces were defined for each potentially platform-specific aspect of functionality (e.g., "About", "Pref-erences", etc.), and the application attempts to register a handler with the platform manager that will pass a requestfor functionality back to the host application. If the registration fails, or if no manager object can be obtained forthe current system, then the application will provide "normal" menu entries for access to that functionality; other-wise, it can be assumed that presentation of this aspect of the system will be taken care of by the OS/JVM on theapplication's behalf.

The allocation of the platform manager is managed using a combination of standard system properties – specifically,the "os.name" property – and the Java Reflection API, so that managers for new platforms may be defined and"dropped in" as needed. (Currently, only Macintosh OS X requires a platform manager, though test managers werewritten for other platforms during development testing.)

jMKT: Java Maketest

Revision: 1833 25

• Under Windows, Solaris, and many other operating systems, it is up to the application to provide a means by whichthe user may request that an application exit. (In fact, many of these platforms simply allow the user to close downtop-level windows one by one, and simply treat the closure of the last window as an implicit request to terminate theapplication.) Under Macintosh OS X, however, the operating system/JVM provides an explicit means of terminatingthe application via an item on the "application menu": the default operation triggered by this item is the immediatetermination of the JVM without providing a chance for a more "graceful exit" (e.g., allowing the user to savemodified files, etc.). Apple provides a means by which this default behavior may be overridden, but requires thatan object which implements an Apple-specific interface be registered using an equally Apple-specific API.

This issue was handled by defining a QuitHandler interface, and adding support to the PlatformMgr classfor its registration with this system. In the OS X version of the platform manager, requests to quit the applicationare deferred to the main application object, which walks through a list of top-level windows and signals each onethat it should close itself. If a given window contains content that has been modified and not yet saved, the user isgiven the opportunity to save or discard the changes, or to cancel the operation. If all top-level windows are closed,then the application exits as it would under any platform; otherwise, the OS/JVM is signalled that the applicationshould not be terminated, and normal usage may continue.

6.2. MKT content conversion issuesThe task of automatically converting MKT content to a new format was made more difficult by a number of factors:

• MKT uses a somewhat free-form mixture of roff markup (including eqn, tbl, and fig content) for formatting, andcustom markup for component identification (e.g., questions, answers, background text, etc.) Not all of the roffformatting markup options are supported by the conversion script at this time, though a fairly large subset of theoptions commonly used within the CS3 and CS4 question pools are handled directly.

In the case where unsupported roff formatting markup is identified by the conversion script, an XML comment isinserted into the jMKT content, containing the tag text "FIXME (jMKT):". This allows the user to easily search forfiles containing unconverted content, which can then be edited by hand in order to complete the conversion process.

• MKT does not require that all components of a given question type be present within a question file. (For example,it is possible for an MKT file to include no markup identifying the type of question or even that it is an MKT file,instead of a simple text file.)

As a result, the conversion script will perform a series of tests against each target file, in order to identify the typeof content being converted (e.g., "multiple choice", "true/false", etc.). If the content type cannot be conclusivelyidentified, the script will make a "best guess" at the type.

• The roff format does not require that formatting commands be explicitly turned off in some cases, or that they beturned off in any particular order.

As the jMKT format is XML-based, and thus does require that formatting instructions be turned off in the reverseorder that they were applied, the conversion script makes use of a simple push-down automaton (PDA) for thepurpose of trying to ensure this balance. Any errors that may slip through during the conversion process are broughtto the user's attention during the final stage, where the jMKT content is checked to ensure that it meets some basicvalidity constraints (and is well-formed).

jMKT: Java Maketest

Revision: 1833 26

6.3. Resource input streamsJava provides applications with the ability to include "resources" within a JAR file (or on the classpath used to locatedcode), which was a key aspect of the design for jMKT. However, there is no way to specify the paths to an applicationresource files that is compatible with the standard Uniform Resource Locater (URL) format, such as may be usedfor files, web pages, etc. Since one of the design goals for the application was to provide for user extensibility (e.g.,specifying custom templates for questions, adding custom content item types or exam formats, etc.), this raised someissues for the design of the system.

I originally considered adding "source type" flags to the configuration file for the system, allowing the user to specifythe location of a file using two separate pieces of data (e.g., "this item is stored as a resource", and "here is its locationrelative to the application's resources"). However, this approach was somewhat fragile, since new types of locations(e.g., web-based using HTTP, etc.) would need to be coded within base jMKT software, rather than being transparentin nature.

Further research revealed the fact that Java provides a limited ability to define new types of URL protocols, by regis-tering a custom URLStreamHandlerFactory with the JVM.16 This seemed to offer a better path to the goal thanwould breaking the data apart, since a custom factory that added support for a new URL protocol ("rsrc") targetingthe application's resource set could be implemented, while relying on the support native to Java for other (traditional)URL protocols, such as "file", "http", and so forth.

The code for the custom factory class and the two supporting classes required to complete its interface is stored inthe edu.rit.cs.mjh.util.rsrc package. URLs such as "rsrc:///xsl/fo/ExamCore-fo.xsl" arehandled by the factory, and are assumed to be rooted within the JAR file or directory containing the main class forthe application.

6.4. FOP-related issuesThe use of the FOP library to handle printing/exporting of exams and keys provided some problems in its own right.

When I began working on the project, the FOP team was roughly 12-18 months into the task of rewriting the librarylargely from the ground up, including substantial changes to the API, core formatting/layout algorithms, etc. While thechanges promised to eventually yield substantial performance improvements and more complete support for the XSL-FO format, the "improved" library was widely acknowledged not to be ready for production use at the time. As a result,I elected to use the 0.20.5 version of the library, which had been designated the "maintenance" branch of the library.

The 0.20.5 version of the library did not include support for a number of XSL-FO features that would have been useful,and includes a number of known issues with regard to the layout algorithms (e.g., lack of support for "keep-together"hints in the content, occasionally overrunning footer areas with content from the primary section of a page, etc.). Iwas able to address most of these problems by restricting the generation of XSL-FO to those components which aresupported best by the library, and by adding support for additional flags to allow users to force breaks in the contentlayout, etc. I also made sure that the design for jMKT kept most of the usage of FOP isolated to two or three key areas,specifically the "rich preview" display classes in the edu.rit.cs.maketest package, and the actual exportingsupport in the edu.rit.cs.mjh.xml.export package, so that the implementation could be replaced as a newer(stable) version became available.

As of this writing, the FOP team has released several "beta" versions of the revised library, and is expected to releasea final version sometime before the end of 2006. Once a "1.0" version of FOP is released, I plan to replace the useof the 0.20.5 version with the new library.

16 The main factor limiting the ability to extend the set of URL protocols is that a new factory may be registered at most once within a given JVM.

jMKT: Java Maketest

Revision: 1833 27

7. Possible extension points and known limita-tions• Improvements in support for MKT conversion, including automatic conversion of images in unsupported formats

(e.g., xfig data, PostScript, etc.) and eqn content.

• Adding support for a Wiki-style markup language within the content editors, so that formatting can be managedfrom within those tools. (Currently, to add custom formatting, images, etc., the user must edit the raw XML content.)

• Adding support to the content editors, allowing rich content editing/rendering (e.g., inline "bold"/"italics"/etc.),similar to that in a word processing package.

• Adding support for additional types of item pools, such as pool stored in a database, or on a web server.

• Spell checking and/or thesaurus capabilities.

• Support for equation representation, using MathML [http://www.w3.org/Math/] or some other mechanism.

MathML support is partially provided within the upcoming FOP release, using an extension to FOP that uses JEu-clid [http://sourceforge.net/projects/jeuclid/] to translate the MathML content into SVG, which FOP then rendersnormally. However, the usefulness of this extension is somewhat open to question, based on email traffic reportingvarious sizing issues as of November 1, 2005. An approach for handling the MathML within the "live" previewmode (where HTML-based rendering is currently used) would need to be defined. (It's also possible that the "printpreview" mode might not support rendering of the SVG content, but this would need to be investigated.)

• Support for equation editing using embedded tools within the content editors.

• Password protection of test banks and exams.

• A remaining issue is that "print preview" doesn't always do a perfect job with regard to pagination: blank pagessometimes appear when content comes close to filling in the content of the preceding page. (This is an existinglimitation of the FOP AWT previewer support.)

At the time that this report was written, a new version of FOP was being prepared for release, which may includefixes for this issue, as well as performance improvements, support for exporting Rich Text Format (RTF), etc.Replacement of FOP 0.20.5 with this newer version would seem to be highly desirable. However, the underlyingAPI has changed substantially in some key areas, and thus a certain degree of work will be involved in this action.

• Currently, URLs in jMKT content must be absolute, which makes it difficult to manage content under a sharedrepository across multiple systems.17 Supporting the definition of URLs for images, etc. that are relative to theposition of an item pool (or even a location specified in a user's preferences) that contains them (e.g., as a "baseURL") would therefore be an extremely useful feature in this type of environment.

Limited support for this is available through the FOP configuration options [http://xmlgraphics.apache.org/fop/0.20.5/embedding.html#config-internal], which allows the base directory (against which FOP resolves relativeURLs) to be set programatically. However, this would require that the URLs for all relative links be calculated froma single position on a given file system, and that they might need to be recalculated when an item pool at a differentposition was opened, and that sufficient information was stored within the exam document in such a way that thebase directory could be recalculated when the exam was reopened on that system or some other one.

• Preliminary support for exporting exam content as Scalable Vector Graphics (SVG) and Maker Interchange For-mat (MIF) is included in the jMKT application, but is conditionally disabled (using Boolean system properties"ENABLE_SVG_OUTPUT" and "ENABLE_MIF_OUTPUT"), as I was unable to test the results for these formats.Testing/debugging these formats (and fully enabling them, if they are successful) should be performed.

jMKT: Java Maketest

Revision: 1833 28

• Extend the support for "exam properties" (and preferences) to include such things as:

• floating-point value support for fields like "font size", etc.

• support for configurable sets of units (e.g., "points/inches/em", "left/right/center", etc.) for properties related toitem measurements and placement (margins/padding, alignment, etc.)

• Integrated "help" functionality.

• Course list and/or gradebook management functionality.

• Support for online presentation of the tests, either through a hosted web service provided by the vendor, or byexporting the tests to environments like Blackboard or WebCT.

• Support for generating surveys, which often feature different types of questions than do traditional exams.

jMKT: Java Maketest

Revision: 1833 29

8. ConclusionWhen I made my initial proposal for this project to Dr. Heliotis, I had a high degree of confidence in my ability tocarry it out within a reasonably short period. Since I had spent the better part of 4 months experimenting with thetechnologies and design that would be required, I felt sure that it would take no more than perhaps 6-8 months tocomplete the project. In hindsight, this was clearly optimistic, since (as of this writing) it has been roughly 14 monthssince that first meeting.

However, the additional time that has been required has been due primarily to the additional functionality that hasgone into jMKT, beyond my initial concept of what the system would be, rather than because of a misconceptionof the effort involved with any of the originally anticipated components of the system. As jMKT began to reach aninitially usable state, I began "eating my own dog food" and using it to prepare exams for classes that I was teachingat RIT. This experience as a user of the system helped me to identify additional functionality that I felt had to beprovided by the system.18

At this point, I have been using jMKT exclusively to prepare exams for my classes for 3 quarters, with the supportof converted MKT exam content. While there remain a number of ways in which the system could be extended toprovide additional functionality, and I expect to continue working on it in order to provide these improvements, I feelthat its current performance (including "ease of use") is more than sufficient to meet the goals originally defined forthis project.

18 I should also confess that this experience helped me to appreciate at a personal level the urgency that Prof. Carithers attached to supporting the automated/bulk conversion of MKT content intoa form usable by jMKT, which had not been a part of my initial proposal: without that functionality, I might still be working on assembling my first live exam.

jMKT: Java Maketest

Revision: 1833 30

A. Definitions and acronymsTable A.1. Definitions and acronyms

Term Definition

API Application Programming Interface, or the interface that a computer system, library or ap-plication provides in order to allow requests for service to be made of it by other computerprograms, and/or to allow data to be exchanged between them.

AWT Abstract Window Toolkit, a part of the standard API defined by Sun for providing GUIsfor Java programs.

DOM Document Object Model, a platform- and language-neutral interface that allows programsand scripts to dynamically access and update the content, structure and style of XML doc-uments.

FOP Formatting Objects Processor, a print formatter driven by XSL-FO data being prepared asan open-source project by the Apache Software Foundation.

GUI Graphical User Interface, a method of interacting with a computer via a metaphor of directmanipulation of graphical images and widgets in addition to text.

HTML HyperText Markup Language, a non-proprietary format based on Standard GeneralizedMarkup Language (SGML) that is the standard format for publishing hypertext on the WorldWide Web.

JAR A file format based on the popular ZIP file format, which is used for aggregating manyfiles into a single entity. The JAR file format is supported by Java as a building blocks forapplications and extensions, allowing Java class files and/or resources to be distributed asa single packaged application.

jMKT Java Maketest

JVM Stands for "Java Virtual Machine". Allows the performance of a hypothetical hardware plat-form to be simulated in software, allowing Java applications to be run (with theoreticallyidentical results) across a wide range of physical hardware platforms and operating systems.

MathML an application of XML for representing mathematical symbols and formulae.

MIF FrameMaker Interchange Format

PCL Printer Control Language, the page description language (PDL) developed by HewlettPackard and used in many of their laser and ink-jet printers.

PDA Push-down automaton, a type of abstract device in automata theory.

PDF Adobe Portable Document Format, a commonly-used language for capturing formatting in-formation from a variety of desktop publishing applications.

PS Adobe Postscript, a programming language optimized for printing graphics and text.

RTF Rich Text Format, a document file format that was originally developed by Microsoft in1987 (and maintained since then) for cross-platform document interchange.

SAX The Simple API for XML, originally a Java-only API that was the first widely adopted APIfor XML in Java, which has become a "de facto" standard API supported in multiple lan-guages.

SVG Scalable Vector Graphics, an XML markup language for describing two-dimensional vectorgraphics, both static and animated (either declarative or scripted). This is an open standarddefined by the World Wide Web Consortium.

UML The Unified Modeling Language, an object modeling and specification language used insoftware engineering.

jMKT: Java Maketest

Revision: 1833 31

Term Definition

URL Uniform Resource Locator (less formally referred to as a "web address"), a sequence ofcharacters, conforming to a standardized format, that is used for referring to resources, suchas documents and images on the Internet, by their location.

UUID Universally unique identifier ("UUID"), which is guaranteed to be unique.

Valid XML XML content that contains a proper document type declaration and obeys the constraintsof that declaration: element sequence and nesting is valid, required attributes are provided,attribute values are of the correct type, etc. (It is worth noting that in order for XML contentto be valid, it must also be well-formed.

W3C The World Wide Web Consortium, an international consortium where member organiza-tions, a full-time staff, and the public, work together to develop standards for the World WideWeb. The W3C also engages in education and software development services supportingtheir aims.

Well-formed XML XML content that obeys the syntax of XML. A document that includes sequences of markupcharacters that cannot be parsed or are invalid cannot be well-formed.

XHTML Extensible HypertText Markup Language, a markup language that has the same expressivepossibilities as HTML, but a stricter syntax.

XML Extensible Markup Language, a W3C-recommended general-purpose markup language forcreating special-purpose markup languages, capable of describing many different kinds ofdata.

XSL Extensible Stylesheet Language, a set of language technologies for defining XML documenttransformation (XSLT) and presentation (XSL-FO).

XSL-FO Extensible Stylesheet Language Formatting Objects, an XML markup language for docu-ment formatting, including physical page layout, typographical elements, etc.

XSLT Extensible Stylesheet Language Transformations, an XML-based language used for thetransformation of XML documents by reading the content of one XML document and ap-plying various rules in order to generate one or more new documents (which may or maynot be in XML format).

jMKT: Java Maketest

Revision: 1833 32

B. UML diagrams

B.1. Core interfaces

Figure B.1. Core interfaces from edu.rit.cs.jmkt

jMKT: Java Maketest

Revision: 1833 33

B.2. jMKT type implementations

Figure B.2. Exam implementation from edu.rit.cs.jmkt

jMKT: Java Maketest

Revision: 1833 34

Figure B.3. Content item implementations from edu.rit.cs.jmkt

jMKT: Java Maketest

Revision: 1833 35

jMKT: Java Maketest

Revision: 1833 36

Figure B.4. Platform manager types from edu.rit.cs.mjh.util.platform

jMKT: Java Maketest

Revision: 1833 37

C. Screenshots

C.1. Question editors

Figure C.1. Essay question editor (under MS Windows)

jMKT: Java Maketest

Revision: 1833 38

Figure C.2. "True/false" question editor (running under MS Windows)

jMKT: Java Maketest

Revision: 1833 39

Figure C.3. "Matching" question editor (running under MS Windows)

jMKT: Java Maketest

Revision: 1833 40

Figure C.4. "Multiple choice" question editor (running under MS Windows)

Figure C.5. Text item editor (under MS Windows)

jMKT: Java Maketest

Revision: 1833 41

Figure C.6. "Multiple answer" question editor (running under MS Windows)

jMKT: Java Maketest

Revision: 1833 42

C.2. Exam editing

Figure C.7. Exam editor, windows tiled (under MS Windows)

In this screen shot, the user has opened:

• A "fast" preview of the exam document (i.e., an HTML-based rendering of the exam as it would be provided tostudents).

• A "concept coverage" report, outlining the number of points associated with each of the concepts addressed by oneor more questions on the exam.

It is worth noting that the total number of points across all of the concepts listed in the "content coverage" reportexceeds the total number of points on the exam, since a given question may be associated with more than oneconcept, and thus may be "double-counted" in the concept coverage report.

• A "fast" preview of the answer key for the exam.

• A preview of one question being considered for inclusion on the exam, displaying both the question and correctanswer, as well as any instructor's notes from the item.

jMKT: Java Maketest

Revision: 1833 43

Figure C.8. Exam editor, windows cascaded (under Macintosh OS X)

jMKT: Java Maketest

Revision: 1833 44

C.3. Miscellaneous

Figure C.9. Gallery dialog, presented on simple startup (under Solaris/CDE)

Figure C.10. Exam properties dialog (under Macintosh OS X)

jMKT: Java Maketest

Revision: 1833 45

D. Sample documents

D.1. Content items (questions)

Figure D.1. Text-only item

<item xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" contentId="24792613095731d2:-2e501aa0:100737bbec6:-8000" points="0" numbered='false' > <textItem> <author>Ken Reek</author> <concepts /> <summary>Extra-credit section header</summary> <text> The following questions are extra credit. You may skip them if you wish to. Correct answers to these questions will raise the grade of a randomly chosen student by the indicated number of points. Incorrect answers will lower your grade by twice the indicated number of points. </text> <instructorNotes /> </textItem></item>

Figure D.2. True/false question

<item xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" contentId="24792613095731d2:-2e501aa0:100737bbec6:-8000"> <tf> <author>Ken Reek</author> <concepts> <concept>Animal husbandry</concept> <concept>Avionics</concept> </concepts> <summary>Flying pigs</summary> <text>(Sometimes we wonder about Ken's questions.)</text> <tf-question answer="false"> If pigs had wings, they could fly. </tf-question> <instructorNotes> Not completely true: they might need afterburners.... </instructorNotes> </tf></item>

jMKT: Java Maketest

Revision: 1833 46

Figure D.3. Multiple choice question

<item xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" contentId="24792613095731d2:-46ee2b8a:100737c34c1:-8000" points="10" > <multipleGuess> <author>Ken Reek</author> <author>Matt Healy</author> <concepts> <concept>Career development</concept> </concepts> <summary>Faculty motivation</summary> <text> Becoming a faculty member at RIT takes a lot of hard work, both in gaining the knowledge and experience that we try to pass on, and in dealing with the day-to-day requirements of teaching (grading, lecturing, taking Fridays off, etc.). </text> <mg-question> The reason that we teach for a living <em>must</em> be because we: </mg-question> <mg-answer> like to earn the big bucks </mg-answer> <mg-answer> feel a deep commitment to helping our fellow human beings </mg-answer> <mg-answer> enjoy the many scholarly interchanges we have with each of our students </mg-answer> <mg-answer> are hooked on snorting chalk dust </mg-answer> <!-- optional tags (mg-aota/mg-nota): they may/may not appear, and *** their content is optional (but will be replaced by stock data *** if they are empty. *** If they *do* appear, they will always be displayed at the *** end of the answer list, with "aota" first, and then "nota" --> <mg-aota>They all sound reasonable</mg-aota> <mg-nota correct="true" /> </multipleGuess></item>

jMKT: Java Maketest

Revision: 1833 47

Figure D.4. Essay question

<item xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" contentId="39e706a46ad531be:fdb413:1083266fabe:-8000"> <essay> <author>Ken Reek</author> <concepts> <concept>Unclassified</concept> </concepts> <summary>Terminology</summary> <essay-question> Define "geek". </essay-question> <essay-answer> <p> A being that apparently took a wrong turn in the human race. Has an incredibly high IQ that leaves no room for personality. </p> <p> Natural Habitat: Computer terminals and video games. </p> <p> See also: Computer Scientist, Engineer. </p> </essay-answer> </essay></item>

jMKT: Java Maketest

Revision: 1833 48

Figure D.5. Fill-in-the-blank question

<item xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" contentId="39e706a46ad531be:fdb413:1083266fabe:-8000"> <essay> <author>Ken Reek</author> <concepts> <concept>Pay scales</concept> </concepts> <summary>Terminology</summary>

<text> Fill in the blanks in the following sentence. </text> <essay-question> The Department of Computer Science is where _______________________ is taught. The faculty and staff are all _______________________, and they deserve _______________________ in their _______________________. </essay-question> <essay-answer> 1) Computer Science<br /> 2) fantastic<br /> 3) large raises<br /> 4) salaries </essay-answer> </essay></item>

jMKT: Java Maketest

Revision: 1833 49

Figure D.6. Matching question

<item xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" contentId="24792613095731d2:-19743885:100737c9087:-8000" new-page-before="true" > <matching> <author>Ken Reek</author> <concepts> <concept>Higher education</concept> <concept>Geography</concept> </concepts> <summary>School location descriptions</summary> <text> Match each of the schools listed below with the phrase best describing its geographical location. </text> <match-questions> <match-question ansId="-1">SUNY Buffalo</match-question> <match-question ansId="2">Cornell</match-question> <match-question ansId="3">Alfred</match-question> <match-question ansId="2">RIT</match-question> <match-question ansId="0">MIT</match-question> </match-questions> <match-answers> <match-answer answer-id="1">up a creek</match-answer> <match-answer answer-id="2">gorgeous</match-answer> <match-answer answer-id="3">in the sticks</match-answer> <match-answer answer-id="4">Quiet, peaceful, and sunny</match-answer> <match-answer answer-id="5">The armpit of the universe</match-answer> <!-- "special" answers, similar to mg-nota/mg-aota --> <match-aota>could be any of the above</match-aota> <!-- "match-aota" always has answer-id=0 --> <match-nota>just east of nowhere</match-nota> <!-- "match-nota" always has answer-id=-1 --> </match-answers> </matching></item>

jMKT: Java Maketest

Revision: 1833 50

Figure D.7. Multiple answer question

<item xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" contentId="37cb61f8f3397d86:a8739b:10786891048:-8000"> <multipleAnswer noscramble="true"> <author>Matt Healy</author> <concepts> <concept>West Wing</concept> </concepts> <summary>West Wing characters</summary> <ma-question> Which of the following characters from the TV show "The West Wing" are not lawyers? </ma-question> <ma-answer correct="true">C.J. Craig</ma-answer> <ma-answer>Josh Lymann</ma-answer> <ma-answer>Sam Seybourne</ma-answer> <ma-answer correct="true">Jed Bartlett</ma-answer> <ma-aota /> <ma-nota /> <instructorNotes /> </multipleAnswer></item>

jMKT: Java Maketest

Revision: 1833 51

D.2. Exam document<?xml version="1.0" encoding="UTF-8"?><jmktDoc> <props> <propGroup name="exam"> <property name="instructor" type="text" stock="true" /> <property name="term" type="text" stock="true" examOnly="true" /> <property name="course-name" type="text" stock="true" examOnly="true" /> <property name="course-section" type="text" stock="true" examOnly="true" /> <property name="type" type="text" stock="true" examOnly="true" /> <property name="time" type="text" stock="true" examOnly="true" /> </propGroup> <propGroup name="matching-questions"> <property name="nota-default-text" type="text" stock="true">None of the above</property> <property name="aota-default-text" type="text" stock="true">All of the above</property> </propGroup> <propGroup name="multiplechoice-questions"> <property name="nota-default-text" type="text" stock="true">None of the above</property> <property name="aota-default-text" type="text" stock="true">All of the above</property> </propGroup> <propGroup name="tf-questions"> <property name="true-default-text" type="text" stock="true">True</property> <property name="false-default-text" type="text" stock="true">False</property> </propGroup> <propGroup name="item-formatting"> <!-- Item spacing constants --> <property name="top-border" type="dimension" stock="true">.25in</property> <property name="bottom-border" type="dimension" stock="true">.25in</property> <property name="align" type="text" stock="true">justify</property> </propGroup> <propGroup name="font"> <property name="family-default" type="text" stock="true">Times</property> <property name="code-family-default" type="text" stock="true">monospace</property> <!-- In jMKT 2.0, this should be a floating-point value --> <property name="base-size" type="integer" stock="true">12</property> <!-- In jMKT 2.0, this should be a floating-point value --> <property name="code-base-size" type="integer" stock="true">10</property> </propGroup>

jMKT: Java Maketest

Revision: 1833 52

<propGroup name="body"> <property name="margin-top" type="dimension" stock="true">0.7in</property> <property name="margin-bottom" type="dimension" stock="true">0.7in</property> <property name="margin-left" type="dimension" stock="true">0.7in</property> <property name="margin-right" type="dimension" stock="true">0.7in</property> </propGroup> <propGroup name="page"> <property name="width" type="dimension" stock="true">auto</property> <property name="height" type="dimension" stock="true">auto</property> <property name="margin-top" type="dimension" stock="true">0in</property> <property name="margin-bottom" type="dimension" stock="true">0in</property> <property name="margin-left" type="dimension" stock="true">0in</property> <property name="margin-right" type="dimension" stock="true">0in</property> <!-- *** Note: these are currently "placeholder" properties. --> <property name="header-margin" type="dimension" stock="true">0.5in</property> <property name="footer-margin" type="dimension" stock="true">0.5in</property> </propGroup> <!-- *** Note: these are currently "placeholder" properties. --> <propGroup name="text-attributes"> <!-- text-align: justify | start --> <property name="align-default" type="text" stock="true">start</property>

<!-- hyphenate: true | false (block, character; inherited) --> <property name="hyphenate" type="boolean" stock="true">false</property> </propGroup> </props> <header contentId="24792613095731d2:-628b20a2:10073757740:-8000"> <examHeader flow="true" /> </header> <header contentId="24792613095731d2:16cf2f91:100947181c3:-8000"> <csStockInstructions /> </header> <item contentId="24792613095731d2:-2e501aa0:100737bbec6:-8000"> <tf> <author>Ken Reek</author> <concepts> <concept>Animal husbandry</concept> <concept>Avionics</concept> </concepts> <summary>Flying pigs</summary>

jMKT: Java Maketest

Revision: 1833 53

<tf-question answer="true"> If pigs had wings, they could fly. </tf-question> </tf> </item> <item points="10" contentId="24792613095731d2:-46ee2b8a:100737c34c1:-8000"> <multipleGuess> <author>Ken Reek</author> <author>Matt Healy</author> <concepts> <concept>Career development</concept> </concepts> <summary>Faculty motivation</summary> <text>Becoming a faculty member at RIT takes a lot of hard work, both in gaining the knowledge and experience that we try to pass on, and in dealing with the day-to-day requirements of teaching (grading, lecturing, taking Fridays off, etc.).</text> <mg-question> The reason that we teach for a living <em>must</em> be because we: </mg-question> <mg-answer>like to earn the big bucks</mg-answer> <mg-answer>are hooked on snorting chalk dust</mg-answer> <mg-answer>enjoy the many scholarly interchanges we have with each of our students</mg-answer> <mg-answer>feel a deep commitment to helping our fellow human beings</mg-answer> <mg-aota>They all sound reasonable</mg-aota> <mg-nota correct="true" /> </multipleGuess> </item> <item contentId="24792613095731d2:3404bf20:100737aa42d:-8000"> <essay> <author>Matt Healy</author> <concepts> <concept>Code analysis</concept> </concepts> <summary>Simple code analysis</summary> <text> Here is some source code: <codefrag>public class Foo { public static void main( String args[] ) { System.out.println( "Bar" ); } }</codefrag> </text> <essay-question space-after="3in"> What can be said of this code? </essay-question> <essay-answer>That it's short, and fairly useless</essay-answer> </essay> </item> <item contentId="24792613095731d2:-19743885:100737c9087:-8000"> <matching> <author>Ken Reek</author> <concepts> <concept>Higher education</concept> <concept>Geography</concept> </concepts> <summary>School location descriptions</summary>

jMKT: Java Maketest

Revision: 1833 54

<text>Match each of the schools listed below with the phrase best describing its geographical location.</text> <match-questions> <match-question ansId="-1">SUNY Buffalo</match-question> <match-question ansId="2">Cornell</match-question> <match-question ansId="3">Alfred</match-question> <match-question ansId="1">RIT</match-question> <match-question ansId="0">MIT</match-question> </match-questions> <match-answers> <match-answer answer-id="1">up a creek</match-answer> <match-answer answer-id="3">in the sticks</match-answer> <match-answer answer-id="2">gorgeous</match-answer> <match-answer answer-id="4"> Quiet, peaceful, and sunny </match-answer> <match-answer answer-id="5"> The armpit of the universe </match-answer>

<!-- "special" answers, similar to mg-nota/mg-aota --> <match-aota>could be any of the above</match-aota> <!-- always has answer-id=0 -->

<match-nota>just east of nowhere</match-nota> <!-- always has answer-id=-1 --> </match-answers> </matching> </item> <item new-page-before="false" contentId="24792613095731d2:2cbef28e:100737b70a7:-8000"> <essay> <author>Matt Healy</author> <author>Monty Python</author> <concepts> <concept>Humor</concept> </concepts> <summary>Keeper of the bridge question</summary> <text> Any man seeking to cross a certain bridge <em>must</em> answer a question of the guardian. Your question is this: </text> <essay-question>What is your name?</essay-question> <essay-answer>Arthur, King of the Britons</essay-answer> </essay> </item> <item points="6" new-page-before="true" contentId="34792613095731e2:-202c2ae:100737e1971:-8000"> <multipleAnswer> <author>Matt Healy</author> <concepts> <concept>Simple examples</concept> </concepts> <summary>Simple multiple-answer example</summary> <ma-question> Pick all of the odd numbers from the following list: </ma-question> <ma-answer>1</ma-answer> <ma-answer correct="true">2</ma-answer>

jMKT: Java Maketest

Revision: 1833 55

<ma-answer correct="false">3</ma-answer> <ma-answer correct="true">4</ma-answer> <ma-nota /> </multipleAnswer> </item></jmktDoc>

jMKT: Java Maketest

Revision: 1833 56

D.3. jMKT configuration fileThe jMKT configuration file is used to define mappings of content types to supporting data, such as stylesheetssupporting their use, custom classes/editors used to support them at run-time, etc. The configuration file is maintainedon a user-specific basis (allowing per-user customization of the application settings, including augmentation with newquestion types/templates), and is initialized from a "stock" file included in the resources within the JAR file for jMKT.

<?xml version="1.0" encoding="UTF-8"?>

<jmktSettings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation='http://www.cs.rit.edu/~mjh/project/jmkt/Schema/jmktSettings.xsd' >

<!-- *** Item mappings specify the stylesheets to be included in order to *** ensure correct processing of a specific item type, and (optionally) *** the custom class that will be used to manipulate them in memory. *** (By default, the "edu.rit.cs.mkt.BasicItem" class will be *** used for this purpose.) --> <itemMappings> <!-- *** Defines some basic settings, used by everything. --> <item name="--stylesheet-items-base--"> <htmlStylesheet>rsrc:///xsl/html/ExamCore-html.xsl</htmlStylesheet> <foStylesheet>rsrc:///xsl/fo/ExamCore-fo.xsl</foStylesheet> </item> <!-- *** Definitions of data specific to various content types follow. --> <item name="textItem"> <htmlStylesheet>rsrc:///xsl/html/text-items-html.xsl</htmlStylesheet> <foStylesheet>rsrc:///xsl/fo/text-items-fo.xsl</foStylesheet> <customClass>edu.rit.cs.jmkt.BasicItem</customClass> <!-- Default value --> <editor>edu.rit.cs.maketest.editors.TextContentEditor</editor> <contentTemplate>templates/textItem.xml</contentTemplate> </item> <item name="tf"> <htmlStylesheet>rsrc:///xsl/html/tf-questions-html.xsl</htmlStylesheet> <foStylesheet>rsrc:///xsl/fo/tf-questions-fop.xsl</foStylesheet> <customClass>edu.rit.cs.jmkt.TFItem</customClass> <editor>edu.rit.cs.maketest.editors.TrueFalseEditor</editor> <contentTemplate>templates/tfItem.xml</contentTemplate> </item> <item name="multipleGuess"> <htmlStylesheet>rsrc:///xsl/html/mc-questions-html.xsl</htmlStylesheet> <foStylesheet>rsrc:///xsl/fo/mc-questions-fop.xsl</foStylesheet> <customClass>edu.rit.cs.jmkt.MultipleGuessItem</customClass> <editor>edu.rit.cs.maketest.editors.MultipleChoiceEditor</editor> <contentTemplate>templates/multipleChoiceItem.xml</contentTemplate> </item> <item name="essay"> <htmlStylesheet>rsrc:///xsl/html/essay-questions-html.xsl</htmlStylesheet>

jMKT: Java Maketest

Revision: 1833 57

<foStylesheet>rsrc:///xsl/fo/essay-questions-fop.xsl</foStylesheet> <customClass>edu.rit.cs.jmkt.EssayItem</customClass> <editor>edu.rit.cs.maketest.editors.EssayEditor</editor> <contentTemplate>templates/essayItem.xml</contentTemplate> </item> <item name="multipleAnswer"> <htmlStylesheet>rsrc:///xsl/html/ma-questions-html.xsl</htmlStylesheet> <foStylesheet>rsrc:///xsl/fo/ma-questions-fop.xsl</foStylesheet> <customClass>edu.rit.cs.jmkt.MultipleAnswerItem</customClass> <editor>edu.rit.cs.maketest.editors.MultipleAnswerEditor</editor> <contentTemplate>templates/multipleAnswerItem.xml</contentTemplate> </item> <item name="matching"> <htmlStylesheet>rsrc:///xsl/html/match-questions-html.xsl</htmlStylesheet> <foStylesheet>rsrc:///xsl/fo/match-questions-fop.xsl</foStylesheet> <customClass>edu.rit.cs.jmkt.MatchingItem</customClass> <editor>edu.rit.cs.maketest.editors.MatchingEditor</editor> <contentTemplate>templates/matchingItem.xml</contentTemplate> </item> </itemMappings> <!-- *** Defines mappings of header content to classes/stylesheets/etc. --> <headerMappings> <header name="examHeader"> <htmlStylesheet>rsrc:///xsl/html/exam-header-html.xsl</htmlStylesheet> <foStylesheet>rsrc:///xsl/fo/exam-header-fo.xsl</foStylesheet> <customClass>edu.rit.cs.jmkt.BasicHeader</customClass> <!-- Default value --> </header> <header name="csStockInstructions"> <htmlStylesheet>rsrc:///xsl/html/cs-stock-instructions-html.xsl</htmlStylesheet> <foStylesheet>rsrc:///xsl/fo/cs-stock-instructions-fo.xsl</foStylesheet> <customClass>edu.rit.cs.jmkt.BasicHeader</customClass> <!-- Default value --> </header> </headerMappings> <!-- *** Defines mappings of trailer content to classes/stylesheets/etc. --> <trailerMappings> <trailer name="pageNumbering"> <htmlStylesheet>rsrc:///xsl/html/exam-pageNum-html.xsl</htmlStylesheet> <foStylesheet>rsrc:///xsl/fo/exam-pageNum-fo.xsl</foStylesheet> <customClass>edu.rit.cs.jmkt.BasicTrailer</customClass> <!-- Default value --> </trailer> </trailerMappings>

</jmktSettings>

jMKT: Java Maketest

Revision: 1833 58

BibliographyAdler, Sharon, et.al. Extensible Stylesheet Language (XSL) Version 1.0. [http://www.w3.org/TR/2001/REC-

xsl-20011015/] . World Wide Web Consortium. 15 Oct. 2001.

Allman, Eric P. Writing Papers with NROFF using -me [http://docs.freebsd.org/44doc/usd/19.memacros/paper.pdf],BSD 4.4 documentation.

Allman, Eric P. -ME Reference Manual [http://docs.freebsd.org/44doc/usd/20.meref/paper.pdf], BSD 4.4 documen-tation.

Apache XML Project, Formatting Object Project web site [http://xml.apache.org/fop/].

Barron, David. Text Processing and Typesetting With Unix. Reading, MA: Addison-Wesley Publishing Company,Inc., 1987.

Biron, Paul V., et.al. XML Schema Part 2: Datatypes Second Edition [http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/]. World Wide Web Consortium. 28 Oct. 2004.

Clark, James. XSL Transformations (XSLT) Version 1.0 [http://www.w3.org/TR/1999/REC-xslt-19991116]. WorldWide Web Consortium. 16 Nov. 1999.

Fallside, David, et.al. XML Schema Part 0: Primer Second Edition [http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/]. World Wide Web Consortium. 28 Oct. 2004.

McLaughlin, Brett. Java & XML (2nd ed.). Sebastopol, CA: O'Reilly & Associates, Inc., 2001.

Pawson, Dave. XSL-FO: Making XML Look Good in Print. Sebastopol, CA: O'Reilly & Associates, Inc., 2002.

Reek, Kenneth A. Personal interview. 18 March 2004.

Reek, Kenneth A. A User's Guide to Maketest, RIT. 13Feb92.

Thompson, Henry, et.al. XML Schema Part 1: Structures Second Edition [http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/]. World Wide Web Consortium. 28 Oct. 2004.

troff.org, troff.org web site [http://www.troff.org/].

Yergeau, François, et.al. Extensible Markup Language (XML) 1.0 (Third Edition) [http://www.w3.org/TR/2004/REC-xml-20040204/]. World Wide Web Consortium. 04 Feb. 2004.