X-Git-Url: http://gitweb.michael.orlitzky.com/?a=blobdiff_plain;ds=sidebyside;f=doc%2Fman1%2Fhtsn-import.1;h=36efdf81e489c5aa99f0e71a86a2b4864bba900b;hb=8de4b2d3f0c6ca7b447f39316f8839ac575d457f;hp=616f7e85b82850366a2f6081cb879b51698b5ee3;hpb=9b28d5ed0e1570f0890eae1ee01721688c20e266;p=dead%2Fhtsn-import.git
diff --git a/doc/man1/htsn-import.1 b/doc/man1/htsn-import.1
index 616f7e8..36efdf8 100644
--- a/doc/man1/htsn-import.1
+++ b/doc/man1/htsn-import.1
@@ -106,6 +106,26 @@ type are provided with the \fBhtsn-import\fR documentation, in the
should be considered a bug if they are incorrect. The diagrams are
created using the pgModeler tool.
+.SH DATABASE SCHEMA COMPROMISES
+
+There are a few places that the database schema isn't exactly how we'd
+like it to be:
+
+.IP \[bu] 2
+\fIearlylineXML.dtd\fR
+
+The database representations for earlylineXML.dtd and
+MLB_earlylineXML.dtd are the same; that is, they share the same
+tables. The two document types represent team names in different
+ways. In order to accomodate both types with one parser, we had to
+make both ways optional, and then merge the two together before
+converting to the database representation.
+
+Unfortunately, when we merge two optional things together, we get
+another optional thing back. There's no way to say that \(dqat least
+one is not optional.\(dq So the team names in the database schema are
+optional as well, even though they should always be present.
+
.SH NULL POLICY
.P
Normally in a database one makes a distinction between fields that
@@ -204,8 +224,8 @@ Successfully imported schemagen/Odds_XML/19996433.xml.
Processed 1 document(s) total.
.fi
.P
-At this point, the database schema matches the old documents, i.e. the
-ones without \fIAStarter\fR and \fIHStarter\fR. If we use a new
+At this point, the database schema matches the old documents, that is,
+the ones without \fIAStarter\fR and \fIHStarter\fR. If we use a new
version of \fBhtsn-import\fR, supporting the new fields, the migration
is handled gracefully:
.P
@@ -284,6 +304,33 @@ We don't parse this case at the moment, but we do recognize it and report
it as unsupported so that offending documents can be removed. An example
is provided as test/xml/newsxml-multiple-sms.xml.
+.IP \[bu]
+\fIMLB_earlylineXML.dtd\fR
+
+Unlike earlylineXML.dtd, this document type has more than one
+associated with each . Moreover, each has a bunch of
+ children that are supposed to be associated with the s,
+but the document structure indicates no explicit relationship. For
+example,
+
+.nf
+
+ ...
+ ...
+ ...
+ ...
+ ...
+
+.fi
+
+Here the first is inferred to apply to the two s that
+follow it, and the second applies to the single that
+follows it. But this is very fragile to parse. Instead, we use a hack
+to facilitate (un)pickling, and then drop the notes entirely during
+the database conversion.
+
+A similar workaround is implemented for Odds_XML.dtd.
+
.IP \[bu]
\fIOdds_XML.dtd\fR
@@ -316,6 +363,148 @@ report these as unsupported and then \(dqsucceed\(dq so that the
offending document can be removed if desired. An example is provided
as test/xml/weatherxml-backwards-teams.xml.
+.SH DATE/TIME ISSUES
+
+Dates and times appear in a number of places on the feed. The date
+portions are usually, fine, but the times often lack important
+information such as the time zone, or whether \(dq8 o'clock\(dq means
+a.m. or p.m.
+
+The most pervasive issue occurs with the timestamps that are included
+in every message. A typical timestamp looks like,
+
+.nf
+ May 24, 2014, at 04:18 PM ET
+.fi
+
+The \(dqtime zone\(dq is given as \(dqET\(dq, but unfortunately
+\(dqET\(dq is not a valid time zone. It stands for \(dqEastern
+Time\(dq, which can belong to either of two time zones, EST or EDT,
+based on the time of the year (that is, whether or not daylight
+savings time is in effect) and one's location (for example, Arizona
+doesn't observe daylight savings time). It's not much more useful to
+be off by one hour than it is to be off by five hours, and since we
+can't determine the true offset from the timestamp, we always parse
+and store these as UTC.
+
+Here's a list of the ones that may cause surprises:
+
+.IP \[bu] 2
+\fIAutoRacingResultsXML.dtd\fR
+
+The elements contain a full date and time, but no time zone
+information:
+
+.nf
+5/24/2014 2:45:00 PM
+.fi
+
+We parse them as UTC, which will be wrong when stored,
+but \(dqcorrect\(dq if the new UTC time zone is ignored.
+
+.IP \[bu]
+\fIAuto_Racing_Schedule_XML.dtd\fR
+
+The and elements are combined into on field in
+the database, but no time zone information is given. For example,
+
+.nf
+02/16/2013
+08:10 PM
+.fi
+
+As a result, we parse and store the times as UTC. The race times are
+not always present in the database, but when they are missing, they
+are presented as \(dqTBA\(dq (to be announced):
+
+.nf
+TBA
+.fi
+
+Since the dates do not appear to be optional, we store only the race
+date in that case.
+
+.IP \[bu]
+\fIearlylineXML.dtd\fR
+
+The