[Cache from http://www.taxadmin.org/fta/edi/100101mins.html; please use this canonical URL/source if possible.]

Terry Garber opened the meeting with the tentative agenda and welcomed everyone.

The planned agenda:

Monday October 1

9:30 AM -10 AM - Government - Special Meeting - New Member Orientation

10 AM -12 Noon - Full Government Subcommittee

1-5 PM - Government/Task Group 2 (TIGERS)

Wireless Standard discussion - development of X12 standard submission

Tuesday October 2

9 AM-5 PM - Government/Task Group 2 (TIGERS)

XML Standards - IRS 941 Schema & Base Elements; IRS 1120 Schema Progress

XBRL (eXtensible Business Reporting Language) presentation/discussion

Wednesday October 3

9 AM -11 AM - Full Government Subcommittee

Presentation of Wireless Standard Work Proposal to Full Government

1-5 PM - - Government/Task Group 2 (TIGERS)

ebXML-derived XML Base Schema discussion

Wireless Standards recap/revision

XML Standards - Naming Conventions and Schema Examples

________________________________

Monday October 1 -- 1-5 PM - Government/Task Group 2 (TIGERS)

Terry Garber gave a background on ASC X12 (TIGERS).

We began discussion of the Wireless (Mobile Sourcing) Project Proposal. The ASC X12 document is called the Tax Jursidiction Sourcing transaction set. Minor changes were made (conforming Proposal language to X12 strictures and the like), and also certain changes to the TS itself.

There was an issue raised regarding how to address in the transaction set (TS) multiple periods of effectiveness of the information provided. (Jurisdictional designations may change on variable schedules.) An LX Loop could be used, but that would mean many loops, one for each date/period-jurisdictional change.

Second, the newly-proposed NX3 segment is not practicable - would not be approved by the X12 membership. So use of an NX2, with a designation of greater than one (>1) will be employed instead of the NX3.

In the PPA segment, it was explained that future use of digital designators is countenanced, but for now existing Latitude/Longitude segments will be used.

In the Tax Authority segment, the word "property" was taken out of the description, to make it read more generically "to identify a jurisdiction's taxing authority".

The question was raised on whether the Vertex information included as an external code reference must be provided free. It is not clear, and further inquiries will have to be made.

The included TS examples must be revised to show multiple NX2 address segments (and not the NX3). Also, currently there is no "sender" information inside the TS, which may be a problem because the "outside envelope" "sender" information is stripped off upon receipt by an EDI translator. Two N1 address segments were added (to address this).

Refer to http://www.taxadmin.org/fta/edi/wireless.html for the updated Tax Jursidiction Sourcing transaction set and additional resources.

The described changes were made in order to make the TS more usable as EDI, by allowing multiple address inquiries within a single transaction. (With the changes, the proposal was approved by the Government Subcommittee on Wednesday the 3rd.) These changes were also made to help ensure a "smoother ride" during the X12 Technical Assessment Review (in December) and the expected balloting process (following the February meeting).

Tuesday October 2 -- 9 AM-5 PM - Government/Task Group 2 (TIGERS)

Tom Guinan, IBM Global consultant to IRS, gave a presentation on XML Transport and Packaging.

This was draft information, only in the nature of a proposal for further testing.

(Refer to http://www.taxadmin.org/fta/edi/xmldev.html for a PDF/Powerppoint of his remarks and a sample document.)

The intent of the exercise is to determine how best to package for transmission and subsequent processing XML-format 941s, 1120s, and other transactions - all together, if desired.

Issues include: what if the received XML is not well-formed? What if it is not valid XML?

What is intended is a validation of the document as a preliminary matter. Current discussion surrounds what XML is capable of doing, validation-wise, and what it cannot easily do. The work to be accomplished is at the middleware level; after initial vallidation, the data is handed to the IRS mainframe. In addition, how data is handled initially has an effect on data storage in the database. Whether the received data will be stored as actual XML data is still being discussed.

The current work is driven by the 1120 filing requirements, but is designed to be generic.

The objectives are generally to:

- support any return (1120, 941, etc.)

- rely on existing standards

- use existing tools

- reduce training cost

- support the transmission of both XML and binary (spreadsheets, etc.) data

- employ multiple communication channels (dial-up, Internet, FTP, HTTP)

- minimize parsing of a file when the data is only needed for a limited purpose (who transmitter was, preparer was, etc.)

XML Transport

The transport proposal is based on SOAP (Simple Object Access Protocol), and is consistent with its semantics. It is also based on ebXML work in progress, although that work is moving slowly. Underlying transport is based on MIME/multipart messaging, due to the need for binary content.

SOAP with attachments (SOAP v 1.2) capability is needed, for this reason: how the data is sent (FTP, HTTP, etc.) doesn't matter to the SOAP envelope.

(See PPT file at http://www.taxadmin.org/fta/edi/XMLpkg01.pdf for further explanation.)

Can there be multiple batches in a transmission? Yes. One value of the approach is that you can compress only the return data envelope; you can reject just one return (as a separate MIME part); and it provides flexibility in acknowledgment processing as well.

A useful feature is Batch Headers, which use XLink pointers; the header contains a list of returns, with associated pointers to each specific return header, which in turn contains information on each return, without the necessity of having to open each one to obtain that data.

The Return Headers, in turn, have XLink pointers to each return's data. The whole process enables a preliminary determination on whether returns (for example huge 1120 filings) should or can be opened and processed. (XLink is a full W3C Recommendation as of 6-22-01.)

For acknowledgments, it is not envisioned at this point that errors on attachments would be transmitted back to the sender, so a simpler SOAP enveloping method can be used.

A question was asked about security and viruses: is it possible that a binary attachment could contain something like this? A self-extracting zip file could contain a .exe that had a virus/worm. That will have to be considered and addressed.

XML Return Packaging

A generic structure for any kind of return has been devised; the advantage is that the same back-end can process many kinds of returns. The return is thus (1) one XML document, (2) with standard parts, and (3) with a "manifest" listing that includes other documents with appropriate identifying information. So a variety of returns can be prepared separately, and then batched.

Each return has a Return Manifest, and associated return (schedule, statement, etc.) document - and a pointer is created to find it, essentially de-constructing the return, with the capability in software to "put it back together". This approach makes return preparation easier, but a software company or preparer would have to ensure that the "manifest listing"/XLink pointers all work, and that they point to the right documents.

The paradigm change is that now the submission is blown into pieces, with links relating to each other, so the receiving application must have the ability to interpret it as a whole.

1120 XML Schema

Glenda Hayes of Mitre Corp. outlined the current approach ot creation of an 1120 XML schema. One of the main objectives is to validate numeric valuies as appropriate. They have attempted both a "direct" and a "derived" method of representing the return. A "derived" schema (derived from the TIGERS Base Schema model) requires more layers, and is not as "flat" as the "direct" method. (The direct contains 134 lines, and the derived 204 lines.)

The basic problem with a derived approach is that, for example, the element "taxinformation.amount" is not global, so values for that cannot be constrained as easily as IRS desires. (Could be done, but would expand the size of the schema.)

The direct method as now constituted uses 94 separate schemas (forms/schedules) for the 1120/1120S.

Next steps for IRS are:

- "community review" of the 1120, 1120S, 941 schemas (IRS has now set up a listserv on www.topica.com for this purpose - contact Xan Ostro of IRS at Xan.H.Ostro@irs.gov for more information.)

- development of 1041, 1065, 990 schemas

- refinement of IRS XML schema - types and general elements

For the 1120 - the utility of XML is that it permits the specification of valid "values" - but it does not indicate how meaning is conveyed; that's up to the creator. So, who is the intended audience? Software developer, preparer, or taxpayer? The IRS believes it is the software developer, so the schema needs to be unambiguously enumerated for them.

This approach could also lend itself to publication using XML Stylesheets (no need for PDFs anymore).

The IRS approach is to constrain everything - with minimum/maximum inclusions. As well, defining PositiveIntegerTypes, NonNegativeIntegerTypes, DateTypes, etc., is a way for IRS to inventory its needs and "clean house" in its systems. And rather than constrain length in an element type, it may be better to do so externally; that way both state and federal entities can use and define that way.

As to Names, one approach is to use a NameSpace and go with generic NameTypes - e.g., South Carolina EIN, Louisiana EIN, etc.

Possibly review and use IRS common elements - use as a base or starting point, and define a "grammatical structure" convention, for simple and complex types, and element names. They can provide a list of those used in the IRS schemas, so TIGERS can do comparisons, critiques, additions, etc.

Discussion ensued on how to maintain a standard list of such things. FTA might host this on the web.

XBRL Discussion

Luther Hampton presented info on eXtensible Business Reporting Language (XBRL), an effort supported by a consortium created by the Big 5 accounting firms and many EC services vendors.

(Refer to http://www.taxadmin.org/fta/edi/xmldev.html for a PDF/Powerppoint of his remarks and a link to the XBRL website.)

XBRL's focus has been to concentrate on facilitating communication of financial-statement data with an emphasis on two things: (1) what a data value is, and (2) what a data value means.

In the XBRL (Version 1 specification) world, the creators were not sensitive to user-agency names of things (in fact, the taxaonomy provides a label structure for using entities to create their own names of things) but meaning is standard, based on GAAP definitions delineating the meaning of the value associated with a label. XBRL documents are a bag of facts; you use XML style sheets to format any specific document. (One of the differences between this environment, and the tax reporting world, is that there are few standard definitions in the tax reporting world.)

W3C's XML Version 1.0 was not really leveraged in the XBRL Version 1 specification; the failure to use XML meant that XML parser validation could not be employed, along with other limitations. Version 2 of XBRL employs XML Schema and especially linking, and the previous use of Document Type Definition (DTD) validation was dropped. The XBRL taxonomy now has 1800 elements, and the spec does not restrict the length/range of elements.

Wednesday October 3 -- 9 AM -11 AM - Full Government Subcommittee

A brief discussion took place on the proposed 25% ASC X12 dues increase. There has been no increase since 1993.

The agenda item relating to the need or desire for standard XML tags was raised. In a flat XML document structure (like the IRS transmission and packaging proposal presented earlier) you must have specific names for items (i.e. interestaccrued, interestincome, interestpayment, etc.). If you are nesting items, by contrast, the document structure provides context.

What is the goal? A total lexicon of XML tax tags? Whether that's important may depend on how data is exchanged - you need specific names for each items if data is exchanged ad hoc, otherwise you have to impose some context or structure.

From a processing perspective, it's simpler if the data is "flat" - the receiving program knows what to expect, and more unambiguous tags makes data easier to share and re-use.

The working IRS premise is that arithmetic errors would not reject a return; that would take place at a second level of processing. The advantage of "complete and unique" tags is that internal sharing and XML storage is facilitated.

How can data be identified uniquely? "F1120grossreceipts" is clear - it's from IRS, it's 1120 data, and it's gross receipts.The use of the XML Namespace capability can help. It's possible to do a form of "intelligent prefixing" (use of Namespace) and "dumb tags" (interest, interestincome, etc.). There is probably a pretty short list of meta-tags. One thing to remember is that you can't have an ambiguous namespace in a valid XML document.

TASKS

Possibly employ the IRS Withholding Tax (941) family Elements as a base list, compare to the existing EDI Tax Information and Amount data element list, create a strawman and post on the FTA web site for comment, maintaining regular and routine communication among group members.

- Define Global Elements

- Define IRS 1120/941 Elements

- Define Motor Fuel Tax/Sales/other state tax Elements

Process

- IRS will have its 941 XML and 941 EDI folks compare tag names and resolve to one list (Greg Carson volunteered IRS resources)

- add existing known state-needed Withholding Tax element tags to the above list (state resource needed)

- employ a payroll provider to assist in development of universe of tags (Anita Gross and Preston Barnett & Ceridian resources)

- add any necessary additional tags: names, (IRS) data types (IRS may be worst case on field lengths), identify element vs. attribute situations, simple vs. complex type situations (Avra Michaelson & Mitre resource)

- an explanatory discussion of the use of Namespaces is also needed, to explain when these are used (when the existing IRS data type is not to be used, i.e. the state is creating one) (resource needed)

- creation of examples of the above - Reference Implementations - for state and federal filing types (resource needed)

Next Steps

Do a "task progress" conference call in mid-November (to be scheduled) to check on work underway prior to the December meeting in San Diego. Check http://www.taxadmin.org/fta/edi/1204agen.html for meeting logistics.