Why use OMD?

An overview of the OMD project can be found on the OMD page. Please check that page if you interested learning what the OMD project is all about.

OMD news and status information can be found on the News page. Please check that page if you interested in following the on-going work, and changes to the source base.

I recieved a letter from a developer asking what the advantages are to using OMD in his project over more traditional methods. Below you will find a "white paper" on why it is worth it to use OMD when implementing your Magic application (and why it might be useful to upgrade your current project to OMD.)

Implementation

One question that many developers ask when faced with using XML is "Is it worth the extra work or program complexity to implement this in XML?" I personally think that it is easier to implement a system in XML. Let me explain. Unless the database your program is going to use is very simple (for example single hash key/values that could use a Windows INI file or Java configuration file) you will need to create a library/module to access you database. You could also go to an external 3rd party library to access your data. However, there is no real difference here in terms of complexity because many (free) 3rd party libraries exist for accessing XML data. (Here for XML tools.) So the only difference is whether you use a proprietary (one you wrote yourself) library to access your data or an XML library to access your data. Of course using an existing XML library to access your data means that you are using code that has been tested outside of your system and is much farther along than the code you have (especially if your code does not exist yet.) Also, a lot more work has been done to the design of XML databases than you have likely done on your personal database system, so XML files are probably better designed, more robust, and easier to internationalise than any seat-of-the-pants implementations you can create.

An observant reader would probably point out that there are a lot of really well designed libraries out there using other database designs and interfaces. The most common and well defined one being SQL. However, the philosophy of using SQL databases is different than the philosophy of XML databases. SQL systems have a central store of data that is accessed by a client or clients. XML databases are designed to be open and used by many people across the internet. Here is where we come to the key issue of why XML (and OMD) are good for Magic applications. Magic applications have a history of being open systems that are free to users around the internet. It has become part of Magic culture to share information freely among the Magic community. Thus XML (and OMD) are ideal for use in this community. I will now talk about some specific examples of how this might work in a Magic application.

Data Viability and Extensibility

Magic applications make use of a lot of data including Card Info, Set List, Deck Lists, etc. When you write a magic application you are faced with a daunting prospect - you know that your application is going to be out of date every 3 months with the release of a new set. If an application implements OMD this problem goes away. You simply have a directory where the Expansion files are stored and when a new one comes out all you do is plop the file in the directory - the OMD interface knows how to read Expansion files and starts using the new data right away. In addition, this data is accurate because hundreds of users have been reading this file and finding any typos that exist. If a new version of the Expansion comes out, or if WOTC releases errata (in the last two sets there has been errata for cards before they were even released) all that is required is the most current Expansion file.

Given that Neutral Ground Online will maintain a central data store of the most recent files your program could even check automatically for updates to the database.

Communication and Interoperability

Information sharing in Magic is so important that it has even worked its way into the Magic lingo. Files containing deck inforamation stored by apprentice are called .dec files. Because these files may be shared by many people working together (and playing) on the internet often times these "net-community" developed decks are called by their apprentice file name (examples include BadDotDec and Replenish.Dec).

Despite people's complaints about the Dojo Effect, I believe that sharing of information and internet communication is part of the fun of Magic. The original Meta Game conceived of by Richard Garfield has grown into something much greater than just game theory or strategies, it has become an international social community.

OMD support in an application would allow data created by that application to be easilly shared among those community members in ways that can only further enhance their enjoyment of the game and the community.

Consider the following hypothetical scenario. Fantozie has an idea for a deck durring the day and when he gets home he boots up his system and runs his favorite deck constuction program. The program comes up and informs him of errata that has been released by WOTC since the last time he used the program. He then enters his deck and runs some test draws. He is excited. He logs into IRC and transfers the Fantozie.Deck.xml file to his online playing program and does battle for the next few hours tuning the deck as he goes. He is excited to try the deck in the field. Checking his local gaming club schedule he sees there is an event tomorrow that he wants to play in. Unsure if he can build the deck he sends the Deck.xml file to his collection program which informs him of the cards he needs to get before he can construct the deck. A quick email to a friend to borrow the cards and he is all set. Before going to bed he sends the Fantozie.Deck.xml file to his local club's web site for pre-event deck registration.

As you can see I listed about 4 different Magic applications making use of the Fantozie.Deck.xml file. There are of course even more such applications that could exist - for example output from the online playing program could contain Game.xml files detailing the plays taken in a game. These files could be used in reports Fantozie wants to write or as data for analysis tools.

Scalability

One interesting aspect of the XML file format is that data not used by an application can be safely ignored but the file can still be accuratly parsed. Thus enhancements to the OMD standard will always be backwards compatible with any application written to support it. For example, consider the current Expansion XML file, a new version of the OMD standard might allow for user comments, however an Expansion file that contains user comments would still work with an application written for the format. This kind of functionality is almost imposible to implement in traditional flat file databases, but because of the design of XML it is innate.

Standards

Standards are only useful if people implement them. Neutral Ground Online is commited to supporting the OMD standard and will continue to create applications (mostly web based) that use it. But for the standard to become really useful other developers need to also implement support for this standard. I strongly encourage anyone implementing or creating a new version of a Magic application to include support for OMD in their product. The OMD-list and other resources are available to help you if you need them.

Comments are always helpful,
June 1, 2000
Hogan Long

Webmaster's note: this file has been modified in order to bring it into sync with OMD's new homepage at http://omd.sourceforge.net/ All changes have been to correct broken links and mispellings and style.
- November, 2000.