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. We'll be adding more soon.- Duke's event calendar system. You can get up to date feeds from here. You can look at a sample XML files 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.
- Another new source calendar converted from .ics to XML here
- A different new source converted from .csv to XML here.
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
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.
- Prototype/Part 1: a working prototype that successfully loads a single XML file, processes it, 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: an individual project involving adding a GUI and writing up a bit about the design of your code (due same time as part 2)
You should not start the next part until you have gotten TA sign-off on the previous parts.
Grading for Parts 1 and 2
Parts 1 and 2 of the project are group grades. Your grade on parts 1 and 2 makes up 75% of your final grade on the Tivoo project.
Grading for this assignment will be similar to Picassa, but there will be greater premium placed on submitting the various deadlines on time. There are 4 "intermediate" deadlines for the project:
- Prototype code complete deadline
- Part 1 code complete deadline
- Part 1 signoff deadline
- Part 2 code complete deadline
In general, the group as a whole is responsible for getting the entire project signed off on time. In cases where one member is not contributing the issue should be brought to your UTA.
| What you have submitted | Grade |
|---|---|
| Parts 1 and 2 signed off on by final deadline, and all intermediate deadlines met. | A |
| Parts 1 and 2 signed off by final deadline, and one intermediate deadline missed by 72 hours at most | A- |
| Parts 1 and 2 signed off by the final deadline, and two intermediate deadlines missed by 72 hours at most (apiece) | B+ |
| Parts 1 and 2 have been signed off by deadline. | B |
| Only Part 1 has signed off by deadline. | C |
Grading for Part 3 (individual Part)
Part 3 is an individual part. It involves both creating a simple GUI for Tivoo and writing a design document. Your grade on part 3 makes up 25% of your final grade on the Tivoo project. Explicit criteria will be given when Part 3 is released.
