From: http://www.taxadmin.org/fta/meet/2000tech/andrson/ "TaXML Presentation." By Michael Sanzi and Lesley Anderson September 12, 2000 Also in: http://www.taxadmin.org/fta/meet/2000tech/andrson/anderson.ppt [Slide #1] TaXML Presentation Lesley Anderson [Slide #2] Introduction "Straw man" XML-based schema The schema authors Notes: Straw man This schema is presented as a straw man -- it is a starting point for working with XML. The people working on this were all tax professionals with many years of experience. Even though this has been carefully reviewed, there may be inconsistencies in the examples. This proposal may not exactly meet the requirements of the agencies that would use it, simply because there has not been sufficient (any!) communication between developers and customers. The Dev Team Tax professionals with many years experience Worked for 10 years developing commercial tax software for professional use Worked at MS for the last 2 years developing the TaxSaver product XML experience provided by programmers at MS [Slide #3] Agenda Developing a hierarchy Creating the schema Creating the XML data file Validating the XML data file with the schema Displaying data using XSL [Slide #4] Developing a Hierarchy Tax forms and electronic filing Included fields that need data entered Included data only once Exceptions: key fields and placeholders Notes: Tax forms and electronic filing Analyzed forms and flow, and reviewed the electronic filing specs Looked for ways to logically group data, rather than just reiterate the forms Looked for ways to economize the amount of data by avoiding duplication Used descriptive tag names Included entry fields Entered fields on forms are included in the hierarchy Subtotals and non-significant computed fields are not included Included fields that would be computed on a worksheet or a form not supported for this version. These are placeholders for a group of fields that would be entered later. Included data only once If data appeared in more than one place, only included data at its source entry point. For example, advance EIC is entered on the W-2 and then carried to the 1040. In our model, the field only shows on the W-2. [Slide #5] Forms Supported Form 1040 Schedule A Schedule B Schedule C Schedule E (pg.1) Schedule EIC Schedule F Schedule H Schedule J Schedule R Schedule SE Form 1040A Schedule 1 Schedule 2 Schedule 3 Form 1040EZ Form 2210-F Form 2441 Form 4255 Form 4562 Form 4797 Form 4835 Form 8606 Form 8615 Form 8812 Form 8815 Form 8828 Form 8829 Form 8839 Form 8863 Form 9465 Form W-2 Form 1099-INT, DIV, & MISC Form 1099-R Notes: It is somewhat misleading to speak in terms of forms. It is more accurate to say that the fields with entered data, as contrasted with computed data, are included in the schema. [Slide #6] At the Top of the Hierarchy TaXML Authentication Identification KeyID TaxYear Version Major Minor IndividualTax CorporateTax W-2 & W-3 Notes: TaXML XML schemas must have a unique root element. In this case, it's TaXML. There would of course, need to be elements for authentication, signon, and versioning. This is not addressed in this hierarchy except for a couple of placeholders. As security and transmissions needs are determined, this part of the schema will be filled Individual Tax is the top level for both federal and state income tax for individuals. I'm showing Corporate Tax as an example of the level at which another entity would appear in the hierarchy. This could be included as an actual part of the schema, by including it through a namespace or a data island. Also, this type of schema could be used to transmit information from employers and financial institutions to the IRS. [Slide #7] The Taxpayer Element Taxpayer IDNumber Name FirstName MiddleInitial LastName Suffix CompleteName NameControl Age65OrOlder Blind MilitaryIndicator HomePhone WorkPhone PresidentFund Exemption Notes: The Taxpayer Element ID number is the Social Security number. We have used the more general term IDNumber to allow this tag to be used for either SSN or EIN. The taxpayer's name is comprised of the 6 pieces shown. We gather the first, middle initial, last name, and suffix separately to make name control and matching easier. The name is then displayed in full in the CompleteName field. The NameControl represents the same content that is currently used in electronic filing. Whether this would still be needed in this new methodology is unclear. Then we have pulled together other information that is specifically related to the taxpayer. There are a couple of other fields that are in this section that were deleted on this slide due to space constraints. The spouse has an identical element. [Slide #8] Address Address Street Street2 ApartmentSuite City State ZipCode NewAddress Notes: Address The hierarchy was developed looking at federal and California. If California needed a piece of information that would be relevant to federal or another state, that field was added to the federal portion of the hierarchy. An example of this is that Street2 is a second line for the street address. The NewAddress tag is a boolean (Yes/No) field to indicate if this is a new address [Slide #9] FilingStatusInformation FilingStatusInformation FilingStatus MFS Name IDNumber DidNotLiveWithSpouse HeadofHousehold Name IDNumber QWYearSpouseDied MustItemizeIndicator Notes: FilingStatusInformation FilingStatusInformation includes the filing status used in the return. The MFS element was created to group the information needed for the spouse when the status is married filing separately. Under the MFS element is the Name element. This is bolded to show that this element has been previously used. This simplifies the hierarchy by not needing to again list the components. The Head of Household information is for the qualifying dependent. [Slide #10] DependentList DependentList Dependent Name IDNumber Relationship QualifyforTaxCredit QualifiedCareExpense YearofBirth Student Disabled NumberOfMonths PYChildCareIndicator Notes: DependentList Here is the first example of dealing with an element that may occur more than once, or in English, that may be present in the XML data file more than once. Throughout this proposed schema, we have used the word "List" to indicate that more than one of the elements that follows the list is allowed. In short, here is what this hierarchy means: One DependentList is allowed. Within each DependentList, there can be an unlimited number of Dependent elements. Within each Dependent element, there can be only one of the items listed. When we move to examine the schema you will be able to see that this is accomplished using the minOccurs' and maxOccurs' attributes. [Slide #11] Digging Into the Hierarchy Wages Demonstrates adding levels to the hierarchy Shows how state data can be gathered ActivityList Combining business, rental, farm, and farm rentals Depreciation California Integrating state into the mix Notes: Digging Into the Hierarchy We're going to be using a paper handout for this part of the presentation because of space constraints on the screen. We'll take a look at the Wages, ActivityList, and how California is included in the hierarchy. [Slide #12] Creating the TaXML Schema XDR rather than DTD Working in XML Using a browser Using an XML editor Declaring the name space Notes: XDR vs DTD There are several languages for writing schemas; XML Document Type Definitions (DTD) is the only standard one and the most widely used today. Microsoft's XML tools use a proprietary schema language called XML Data Reduced (XDR), which makes a number of improvements over DTD. For example, XDR schemas can specify data types (e.g., decimal number, date) and allowable values of elements, enabling p Microsoft says it will eventually replace XDR with the XML Schema language, currently under development by the W3C with input from Microsoft and other companies. Microsoft also says it will provide automated tools for translating XDR schemas to XML Schema We are using XDR in this schema. Working in XML Now we're going to look at XML. Up until now, the material we've looked at has been the analysis and organization of the material, without actually being in an XML file or schema. I'm opening the schema in the Internet Explorer. So technically what you're looking at is an HTML representation of the schema, rather than pure XML. HTML adds the colors and allows you to expand or collapse parts of the schema to make it easier to view. Declaring the name space The first line in the file is the declaration of the name space. We're using the Microsoft versions of XML for both the schema and the datatypes. [Slide #13] TaXML AttributeType AttributeType tsj state keyfield Format Notes: AttributeTypes The attribute feature allows you to add additional information to an element. This can be used to validate, sort, and display data. TSJ The tsj' attribute is probably one you can figure out with little help. Does anyone know what this is? By adding the tsj' attribute, we set the stage to be able to identify which income belongs to the taxpayer, the spouse, or to them as a couple. This can be used to determine the optimal filing status, and is especially critical to many of the states. State Sourcing income to a particular state or city is integral to the preparation of correct state returns. Keyfield The keyfield attribute might be better named something like check total. [Slide #14] TaXML Data Types Data types fixed.14.4 float boolean date int string Notes: TaXML Data Types Fixed.14.4 Fixed.14.4 is the type used for money fields. Float Used for percentages. Boolean Used for Yes/No or True/False situations. Date Used for dates as long as a word such as various is not permitted. If it is, then must use the string type. Int Used for numeric fields that are not currency String Used for anything else! Text is obvious, but also for IDNumbers, calendar years, etc., where you want to be able to control format. [Slide #15] ElementType Declarations Declaring the elements Order Format Beginning < ElementType Name Content Dt:type Ending />' Notes: Declaring the Elements The methodology we used to generate this schema was to set up a database. This gave us a dependable, stable data source that was easily maintainable. A program was written using C++ that creates the schema. Order Each tag name that we use in the hierarchy must be declared in the schema using the ElementType' statement. The ElementType declaration is best done for an item before it is included as a child of another element. Another way to view this is that the elements that contain text, rather than other elements are handled first. Although the first half of the schema is in alphabetical order, this is only because that was the choice of the programmer to alphabetize the elements that did not have child elements. The order in which a schema is written is not hard and fast. The language is still growing. Format Each line begins with a less than sign. All XML schemas are XML files and must conform to the required XML syntax. Let's look at the AccountingMethod line as an example. Note to self: Go to next slide. [Slide #16] AccountingMethod Example Notes: Begin the line with the less than sign. Next is ElementType to identify what is to be defined. Next is name'. This is the tag name from the hierarchy. Content must be declared using the content="XXX" format. Dt:type="string, boolean, etc" is the format for data type. The ending of the line is />. The slash is used to denote an empty element, if you are familiar with that from your XML class. This simply means that no data will be stored on this line. Content Content identifies the content of the element. The choices that XML allows are eltOnly, textOnly, and mixed. textOnly' means that the element contains data. Although textOnly' sounds like it might only hold string data, this will hold any kind of data. eltOnly' means that this element can only contain other elements. An example of this is the Name element within the Taxpayer element that we looked at early in the presentation. Name contains the elements FirstName and LastName that actually contain the Mixed is not used in this schema. [Slide #17] Building the Tree in XML The tree Declaring elements that contain other elements Example Notes: Note to self: Search on TaXML to find the place in the file. The Tree The tree in an XML schema really just represents the parent-child relationship between elements. [Slide #18] The XML Data File Creating the data file in "real life" Schema under control of IRS XML data files produced by 3rd party software XML data files created by taxpayer entry on IRS web site Typed in for this presentation Demo of the XML file Notes: For this presentation, we simply typed the data into a well-formed XML file and validated it against the schema. All that means is that if we entered data that did not match something in the schema, an error was displayed when we tried to view it in Inter In real life, the schema would be established by the IRS much the same as the electronic filing record layouts and specifications are done currently. Third party software would then produce valid XML data files in the same way that they produce well forme In the near future, we hope to see XML data files produced by a taxpayer's entries into the fields on an IRS web site. Now let's take a look at an XML data file. I'm going to show you this file in an XML editor instead of Internet Explorer just to give you another view of the world. Whether you use this tool or IE, the validations done are the same. I should mention that we have used EF PATS files for our samples, so these may look familiar! [Slide #19] Sample XML Data File Identify the version Include the schema to be used to validate this file Data must be included between correctly named tags Case sensitive End tags No overlap Notes: Version The version is 1.0. To create a sample file of your own, just copy this line. Schema You must give the name (and path if it's in a different directory) of the schema. Well-formed Rules I'm sure you covered these rules in your class yesterday. XML is case sensitive -- not a problem for those who grew up with UNIX. You must have beginning and ending tags. Unlike HTML, the tags may not overlap. [Slide #20] Validation of Data XML validates data against the schema and thus ensures a correctly formed file As with our current electronic filing system, however, there will be a need for checking content There would need to be calculations done with the XML data after transmission of the file to the IRS [Slide #21] Displaying Data With XSL XML data storage versus use of the data XSL is a separate language Very new so hard to find information Uses XML syntax XSL file Notes: XML Storage Vs Display Perhaps the greatest advantage of using XML is the power to store data separately from how you use the data. I'll show you a demo in a minute that displays the same XML data file in two different formats. XSL as a Language Information is beginning to become available about XSL. My latest check of the bookstores shows several good looking books due to be published this summer. Since XSL uses the same syntax as XML, you don't have to learn another language. [Slide #22] Summary Hierarchy XML schema and XML data file XSL Questions? Notes: Hierarchy We covered a possible data hierarchy that would reduce the amount of data to be transmitted. ----------------------------
Prepared by Robin Cover for The XML Cover Pages archive.