2000 Mar 27
Recent revisions to the sales tax proposal affect the following tasks:
Proposal revision: An input clause was introduced, and its address and items subclauses can appear in any order. This change will require more programming of the parsing code and may require changing the existing input parsing code.
Code Changes: address.h, items.h, and parser.h modified to better deal with extraneous whitespace, i.e., whitespace between the initial parenthesis and the keyword and whitespace before the closing parenthesis.
Proposal revision: See the changes to the input clause listed in Section 1.1.
Proposal revision: The address class, not the ZIP class yields the first three, five, and nine digits of a postal code. This is probably a mistake, but this is the specification I told the team so let's stick with that.
Status: Code submitted. Quick test seems to indicate successful ZIP+4 lookup. Needs to be able to handle address objects with state specified with full-length string, not two-character abbreviation. Jeffrey split the code into pieces.
Proposal revision: Class names have been changed to taxJurisdiction and taxRate. The order of hash table lookup has been reversed to, hopefully, reduce the size of the hash tables. The order is now from nine-digit to three-digit. Thus, the three-digit hash table should be filled with data, but the other ones will just have exceptions to the preceding hash table.
Proposal revision: A taxability clause must begin with the keyword taxability, and the first subclause must be a upc subclause. The default subclause may have an unknown argument, and only the last occurrence of this subclause is used to determine the default taxability status. If no entry for a particular item is found, its taxability is considered notFound, rather than unknown. unknown means the tax laws are ambiguous or not defined. notFound means our server does not have information on the specified item.
Proposal revision: An output specification was added. This needs to be programmed.