Fix a bug in the AutoRacingResults template Haskell.

[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..450ad7a9b9cbac19a0e2d1b71aadf83ff3e66ea6 100644 (file)
--- a/doc/man1/htsn-import.1
+++ b/doc/man1/htsn-import.1
@@ -48,6 +48,8 @@ pickle/unpickle everything already, this should be impossible.
 The XML document types obtained from the feed are uniquely identified
 by their DTDs. We currently support documents with the following DTDs:
 .IP \[bu] 2
+AutoRacingResultsXML.dtd
+.IP \[bu]
 Auto_Racing_Schedule_XML.dtd
 .IP \[bu]
 Heartbeat.dtd
@@ -63,18 +65,78 @@ Odds_XML.dtd
 scoresxml.dtd
 .IP \[bu]
 weatherxml.dtd
+.IP \[bu]
+GameInfo
+.RS
+.IP \[bu]
+CBASK_Lineup_XML.dtd
+.IP \[bu]
+cbaskpreviewxml.dtd
+.IP \[bu]
+cflpreviewxml.dtd
+.IP \[bu]
+Matchup_NBA_NHL_XML.dtd
+.IP \[bu]
+MLB_Gaming_Matchup_XML.dtd
+.IP \[bu]
+MLB_Lineup_XML.dtd
+.IP \[bu]
+MLB_Matchup_XML.dtd
+.IP \[bu]
+MLS_Preview_XML.dtd
+.IP \[bu]
+mlbpreviewxml.dtd
+.IP \[bu]
+NBA_Gaming_Matchup_XML.dtd
+.IP \[bu]
+NBA_Playoff_Matchup_XML.dtd
+.IP \[bu]
+NBALineupXML.dtd
+.IP \[bu]
+nbapreviewxml.dtd
+.IP \[bu]
+NCAA_FB_Preview_XML.dtd
+.IP \[bu]
+NFL_NCAA_FB_Matchup_XML.dtd
+.IP \[bu]
+nflpreviewxml.dtd
+.IP \[bu]
+nhlpreviewxml.dtd
+.IP \[bu]
+recapxml.dtd
+.IP \[bu]
+WorldBaseballPreviewXML.dtd
+.RE
+.IP \[bu]
+SportInfo
+.RS
+.IP \[bu]
+CBASK_3PPctXML.dtd
+.IP \[bu]
+Cbask_All_Tourn_Teams_XML.dtd
+.IP \[bu]
+CBASK_AssistsXML.dtd
+.IP \[bu]
+Cbask_Awards_XML.dtd
+.IP \[bu]
+CBASK_BlocksXML.dtd
+.RE
+.P
+The GameInfo and SportInfo 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 \(dqsport_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 +168,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
+\(dqsport_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 sport_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 +185,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