What functions should we write for the design deadline?
None whatsoever. All you need to turn in for the design deadline is your set of data definitions and a representative portion of the form as captured in your definitions. For example, we were able to write examples of slideshow talks before we wrote the interpreter. Something akin to a sample talk program is what we're expecting with your design.
How do we handle references to page numbers in the tax instructions?
Ignore them. We'll give you formulas that depend only on the data in the tax form for each of those cases.
How do we handle references to blacked-out lines numbers?
Assume they contain zero.
Do we need to handle the extra information on the filing status lines? (Widow date, etc)
No. You can treat the filing status as a simple symbol with no other information required.
What do we do with the name/SSN info when we print out the result of the form?
You can ignore them if you want. We left them in as a means of exercising your design, not your implementation.
How do we handle the address and SSN of payers in part 1 of schedule B?
You can ignore those and just include the name of the payer.
What do we do about the preparer's signature?
You can ignore everything after the "amount you owe" on the 1040 (preparer info, signature, etc).
What will the tax form interpreter do?
The tax form interpreter will prompt a user for all of the data needed to complete the tax form and calculate the taxes owed. Your tax form language should contain the info that the interpreter will need to request data and perform the calculation.
Should the user enter data from lines that copy info from one line of the form to another?
No. Your program should handle this automatically. Since the point of a tax program is to save the user from unnecessary work, your interpreter should only query the user when needed data isn't already available.