Q2: Can you describe a project that uses XML?

Please describe a project in which you have used the eXtensible Markup Language. What was the purpose of this project, and who was the audience? Were there multiple authors? What was your design process like? Did you use any brainstorming tools or audience analysis techniques to help structure your XML hierarchy or did you "code from scratch"? Did the structure of your XML document (e.g. elements and attributes and relationships between them) remain the same throughout the duration of the project, or were revisions necessary?


JMM: The Cast Member Performance Management Project (CMPM) is developing a theory and practice for managing the behavior of actors in learning-oriented multi-player online role playing games (MORPG). A central tool of CMPM is the Cast Performance Management System (CPMS), a distributed Java and PHP application that coordinates the activities of online actors. The purpose is to provide new ways of using computer game technology for learning in K-12 and university education. Its ultimate audience will be the students in schools and universities around the world, we hope. My graduate student Alpesh Makwana and I are authoring these materials, with help from "seasonal labor" (semester-long student projects.) We coded from scratch, but the structure is based on a formal model that we call the Scenario Segment Guide. The structure of our documents (there are several) are constantly evolving as we implement the Java and PHP code and test the resulting system.

MG: At FIEA and EA we use XML in nearly all games to describe many forms of data including visual effects. The purpose of the projects is to entertain, and the audience includes anybody who plays or develops video games. Video game software (e.g. the "engine" and asset conditioning software) effectively has 4 sets of users, each with different requirements: End users who play the games or potentially modify them, artists who supply artistic content ("assets") used in the game, producers and level designers who supply various other kinds of content such as layout and high-level descriptions of autonomous behavior, and other programmers who author everything else. Typically a modern video game for a current console has a team of anywhere from 30 to 150 people. The design process is somewhat formal and includes several phases, starting with the game pitch. After the pitch is approved then preproduction starts, which includes research, design and prototyping. We have employed various tactics including traditional and more recent methods. We used to spend about 6 to 8 weeks writing design documents, then spent the rest of the year writing software. More recently we have started to adopt techniques resembling "SCRUM" where we alternate between design and production. For other parts of the project we have used brainstorming tools such as MindMap, but the XML formats usually derive from higher level requirements of the software design. Often the XML layout has a direct analogy to the classes used to implement the software. More recently we have had a push toward designing the XML separately from the implementation so that we could in principle have file formats that outlive and span across any given implementation so that even if we have multiple competing engine implementations then at least they could share their file formats. In practice we have not adopted that practice yet. We regularly extend the XML format with an eye toward having the new parser continue to accept older files. Most of the time, we add to the existing XML format and rarely change something so drastically that old files fail to work with the new parser.

TG: A recent example project involving XML would be a trivia application. Basically, a list of multiple-choice questions, and feedback depending on whether the person got the question right or wrong. The purpose of the project was to create an interactive educational exhibit, that could randomly select a question from an external file, which could easily be updated by someone without knowledge of programming. The design process usually starts with planning, followed by design of the XML file structure itself. A common tool I use for almost all XML applications is known as ECMAScript for XML, or for short, E4X. It makes parsing and searching the information within an XML file much easier. For most trivia projects, the format stays the same. The main element tags are TRIVIA (the main “wrapper” tag), QUESTION (to “wrap” each question) and ANSWER (child nodes of QUESTION tag). For each set of ANSWER tags inside a QUESTION tag, one of those elements has a “CORRECT” attribute. This format is extremely simple, and rarely needs any revisions. If a revision is needed, it would only be for a special case, such as adding time limits to certain questions.

BA: The product documentation and the automation of its generation is based on the use of XML. From the source code comments in C# code files, which are done in XML tags, to the import of snippet example code, which is kept in XML tagged text files, to the transformation of FrameMaker authored content from XML to HTML, XML is key to the product documentation process. Much of the XML process is standardized and defined. The source code comments are Microsoft conventions. Some of the XML was developed by me and somewhat resembles the organization of types of documentation that is now seen in DITA, with Tasks, Reference, and Topic types. We regularly extend the XML format with an eye toward having the new parser continue to accept older files. Most of the time, we add to the existing XML format and rarely change something so drastically that old files fail to work with the new parser.

SS: The development of an electronic tech manual using Internet Explorer as the browser is based on the use of XML. Our process begins with requirements analysis and planning, design of the XML structure and interactive features, XML tagging and DTD development, test, and implementation. We generally have a technical writer who collects and analyzes the data for the technical manual, but we may have another person setup the XML structure and actually tag the content. Most of the time, this process is driven by schedule, cost, and complexity. Our design and audience approach is based mostly on military specifications and the user environment. Sometimes, we do make adjustments to the structure after the document is tested by the user but rarely anything substantial.



Return to the List of Questions.