Add GameInfo DTDs and an explanation to the man page.

[dead/htsn-import.git] / doc / man1 / htsn-import.1

diff --git a/doc/man1/htsn-import.1 b/doc/man1/htsn-import.1
index 49a6927c4ef7c385f47c086fc1b9d6275170c165..869bb52e0304aaa2988ceb450f033f875181c493 100644 (file)
--- a/doc/man1/htsn-import.1
+++ b/doc/man1/htsn-import.1
@@ -56,25 +56,51 @@ Injuries_Detail_XML.dtd
 .IP \[bu]
 injuriesxml.dtd
 .IP \[bu]
+MLB_Gaming_Matchup_XML.dtd (GameInfo)
+.IP \[bu]
+MLB_Lineup_XML.dtd (GameInfo)
+.IP \[bu]
+MLB_Matchup_XML.dtd (GameInfo)
+.IP \[bu]
+MLS_Preview_XML.dtd (GameInfo)
+.IP \[bu]
+mlbpreviewxml.dtd (GameInfo)
+.IP \[bu]
+NBA_Gaming_Matchup_XML.dtd (GameInfo)
+.IP \[bu]
+NBA_Playoff_Matchup_XML.dtd (GameInfo)
+.IP \[bu]
+NBALineupXML.dtd (GameInfo)
+.IP \[bu]
+nbapreviewxml.dtd (GameInfo)
+.IP \[bu]
 newsxml.dtd
 .IP \[bu]
+nhlpreviewxml.dtd (GameInfo)
+.IP \[bu]
 Odds_XML.dtd
 .IP \[bu]
+recapxml.dtd (GameInfo)
+.IP \[bu]
 scoresxml.dtd
 .IP \[bu]
 weatherxml.dtd
+.P
+The GameInfo and SportsInfo types do not have their own top-level
+tables in the database. Instead, their raw XML is stored in either the
+\(dqgame_info\(dq or \(dqsports_info\(dq table respectively.
 
 .SH DATABASE SCHEMA
 .P
-At the top level, we have one table for each of the XML document types
-that we import. For example, the documents corresponding to
-\fInewsxml.dtd\fR will have a table called \(dqnews\(dq. All top-level
-tables contain two important fields, \(dqxml_file_id\(dq and
-\(dqtime_stamp\(dq. The former is unique and prevents us from
-inserting the same data twice. The time stamp on the other hand lets
-us know when the data is old and can be removed. The database schema
-make it possible to delete only the outdated top-level records; all
-transient children should be removed by triggers.
+At the top level (with two notable exceptions), we have one table for
+each of the XML document types that we import. For example, the
+documents corresponding to \fInewsxml.dtd\fR will have a table called
+\(dqnews\(dq. All top-level tables contain two important fields,
+\(dqxml_file_id\(dq and \(dqtime_stamp\(dq. The former is unique and
+prevents us from inserting the same data twice. The time stamp on the
+other hand lets us know when the data is old and can be removed. The
+database schema make it possible to delete only the outdated top-level
+records; all transient children should be removed by triggers.
 .P
 These top-level tables will often have children. For example, each
 news item has zero or more locations associated with it. The child
@@ -106,6 +132,14 @@ to delete the old games (through an ON DELETE CASCADE, tied to
 unique constraint in the top-level table's \(dqxml_file_id\(dq will
 prevent duplication in this case anyway.
 .P
+The aforementioned exceptions are the \(dqgame_info\(dq and
+\(dqsports_info\(dq tables. These tables contain the raw XML for a
+number of DTDs that are not handled individually. This is partially
+for backwards-compatibility with a legacy implementation, but is
+mostly a stopgap due to a lack of resources at the moment. These two
+tables (game_info and sports_info) still possess timestamps that allow
+us to prune old data.
+.P
 UML diagrams of the resulting database schema for each XML document
 type are provided with the \fBhtsn-import\fR documentation.
 
@@ -115,8 +149,8 @@ There are a number of problems with the XML on the wire. Even if we
 construct the DTDs ourselves, the results are sometimes
 inconsistent. Here we document a few of them.
 
-.IP \[bu]
-2 Odds_XML.dtd
+.IP \[bu] 2
+Odds_XML.dtd
 
 The <Notes> elements here are supposed to be associated with a set of
 <Game> elements, but since the pair