TiVOO

Markup Languages provide a convenient way to combine text data with extra information about the data that eases the processing of the text data. These languages have gained popularity because they let you identify your information in an accurate, flexible, and adaptable way. The best-known markup language in modern use is HTML (HyperText Markup Language), one of the foundations of the World Wide Web because it combines free form text (the data) with links to other documents (the markup). Markup was originally created for the publishing industry to ease the communication of printed work between authors, editors, and printers.

XML is currently the standard for communicating structured data between clients and servers over the web. XML files are organized as a hierarchical collection of tags. There are thousands of XML formats that define their tags used differently, but that share the same basic structure. For example, Apple property files have been stored as XML for years and Microsoft has recently switched to using XML instead binary files for its Office file formats. XML parsers, of varying sophistication, are available for all major programming languages.

In this project, you will process several different XML formats that are based on schedule data and output the results in a variety of ways, i.e., another markup language or a graphical view of the data. The inspiration for this project comes from the functionality of the TiVO digital video recorder and the MythTV open source project. It also serves as an event aggregator that displays data from multiple schedule files at once like Google Calendar, KOrganizer, or Calagator.

Specifications

Working in teams, write a program that processes a variety of XML input files representing scheduled data (e.g., television programming, movie show times, appointments, bus schedules, etc.) and generates an output HTML file of the given schedule. Users should be able to combine any number of XML schedule files into a single table. To constrain the problem, schedules should be limited to the current week or month of data.

Users should be able to see their schedules output to HTML ordered by either time or event or in a tabular form. Given the size of some of the data files, it may help to output the data to multiple files, and provide an index that allows the user to navigate the given schedule. To help create your tables, you may want to "round" events to the nearest hour (or other time increment).

In addition to simply viewing their full schedule, users should be able to filter their views to a specific day, time, type of event, keyword, etc. Users are also interested in finding times that are in conflict, i.e., multiple events are scheduled for the same slot. Finally, users might like to provide themes for their schedules that describe the specific look of the schedule, or just the colors of the events in the schedule.

Eventually, the user should be able to specify options for how the final calendar is displayed (e.g., sort order, shows to record (season passes), themed skins, etc.) as well as being able to interact with the calendar.

XML Formats

Here are a few formats your system should be able to parse.

• Duke's event calendar system. You can get up to date feeds from here. You can look at a sample XML file here.
• Google calendar data. If you want to access your own google calendar, you can find instructions for it here. If you would like the live feed of Michael Hewner's calendar go here or look at a saved version here.
• XMLTV data. You can look find a general introduction to the XMLTV format here. You can download up-to-date TV listings for your cable provider and area, but it might be better to just use the one saved here because the process takes a bit.

Design Goals

A typical architecture for many program designs is one that divides a program's execution into three stages: input, data is provided to the program; process, that data is transformed; and output, the program displays the results of transforming that data. This input/process/output (IPO) model of programming is used in simple programs like this one as well as in million-line programs that forecast the weather or predict stock market fluctuations. Your final program should be clearly separated into three independent modules such that each contains one or more classes that make it flexible enough to accommodate a variety of options without requiring either of the other modules to change. To do this, you must think carefully about what the result of each step is so that it can be safely received by the next step.

For example, each module should be able to be created and ordered easily and flexible in handling its responsibilities:

• Input: read XML formatted files from a variety of sources and provide appointments to be processed
• Process: take appointments and add, remove, combine, sort, reverse or even do nothing to them
• Output: format the appointments in HTML in a variety of orders and styles

In short, to maximize your grade, you should implement enough variety in your program to clearly demonstrate that your design supports further such extensions in each phase of the architecture.

Stages

This project will be released in stages. Part of the reason for this is to encourage you to think about code flexibility. For example, you can see that in each stage, you will be adding a different kinds of functions. If you structure you code in the first part to make it easy to add new kinds of functions, you will have an easier time on the later parts.

• Part 1: a working prototype that successfully loads a single XML file and outputs a single kind of HTML
• Part 2: more kinds of input, processing to filter and sort events, and more styles of HTML output
• Part 3: making the program interactive by building a GUI

You should not start the next part until you have gotten TA sign-off on the previous parts.

Grading

Grading for this assignment is simple, simply get all parts submitted and signed off on. As long as you start each of the parts early and are responsive to TA feedback, you should have no trouble getting full credit. The ultimate goal is to complete the entire project, the stages and sign offs are just our way to help you manage and prioritize the project's tasks. Thus, turning in a part late will not affect your final project grade, but it will leave you with less time to complete the remaining parts on time.

What you have submitted	Grade
The design of your project APIs shows simplicity, power, flexibility, and attention to making objects as active as possible.	A
Parts 1, 2, and 3 have been signed off.	A-
Parts 1 and 2 have been signed off on. Part 3 has been submitted and works, but there are still some style problems so your TA has not signed off.	B+
Parts 1 and 2 have been signed off.	B
Only Part 1 has been signed off.	C

Resources

• Josh Bloch on API Design
• Framework Design Guidelines, Chapter 1, by K. Cwalina and B. Abrams
• On the Criteria to be used in Decomposing a System into Modules by D.L. Parnas
• Technical Resources