EDGAR Information:
Reduced Content XFDL Specification
Version 1.0

Notice: Reduced Content Specification Change — See Appendices Section

Release Notes

Edgar 8.0 server software does not support some of the field identifiers that were valid in the 7.0 and 7.5 versions of the PureEdge templates. EDGAR 7.5 did support backward compatibility with the 7.0 templates, however this support goes away with 8.0. We decided that the nature of the template changes being introduced with 8.0, particularly for fee-bearing submissions, requires us to drop support of the 7.0 and 7.5 templates.

The following list shows the field names from the 7.0 and 7.5 templates that are obsolete as of EDGAR 8.0. The EDGAR 8.0 Receipt server will suspend a submission if it detects any of these obsolete field names or any other unrecognized field.

ROFormType
SubCompany_conformedName_
SubCompany_entityId_
SubCompany_reportingFileNumber_
SubEmail_emailAddress_
SubFee_methodOfPayment_
SubFee_offsetForm_
SubFee_offsetId_
SubFee_totalConvertible_
SubFee_totalDebt_
SubFee_totalEquity_
SubFee_totalOffset_
SubFee_totalOther_
SubGlobal_act_
SubGlobal_delayingAmendmentFlag_
SubGlobal_moduleCount_
SubGlobal_offsetCheckbox_
SubGlobal_paymentMethod_
SubGlobal_payorCheckbox_
SubGlobal_testOrLiveFlag_
SubGlobal_reference462b_
SubGlobal_segmentCount_

Templates 1 and 2 handle all the fee-bearing submission types. We added several new fields (shown in the next listing) to these templates to allow the input of multiple offset payments and offerings. The fee-bearing example submissions in section 8 of this Specification illustrate the use of these new fields.

SubOffering_aggregatePrice_
SubOffering_offeringAmountPerShare_
SubOffering_offeringShares_
SubOffering_securityName_
SubOffset_offsetAmount_
SubOffset_offsetFileNumber_
SubOffset_offsetFilingDate_
SubOffset_offsetForm_
SubOffset_offsetId_

1. Purpose

The EDGARlink portion of the EDGAR web-based filing environment is based on the PureEdge (formerly UWI.COM) XFDL forms specification, which is an extension of the XML specification. An EDGAR filer, from his client machine, must use the PureEdge Viewer application to open an XFDL Template and construct a file that he can then submit via Filer Web Server (FWS). The EDGAR server-side software uses the PureEdge Application Programming Interface (API) to parse the pertinent submission data from the filer's XFDL file.

Roughly 99% of the XFDL content of each EDGAR Template, as well as any submission file saved from the Template, is just needed for the rendering of the Graphical User Interface (GUI). The EDGAR Receipt Server only cares about the 1% of the XFDL that contains the submission-related data. The Server completely ignores all the GUI-related items.

This Specification provides, to those filers who are interested, a basis for creating XFDL filings without the use of the PureEdge Viewer. The expectation is that software developers, working on behalf of filers, will construct software that will generate filings that can be successfully parsed by the EDGAR Receipt Server. These generated filings will only contain the minimum set of XFDL data needed by the Server, hence the term "Reduced Content Filing".

The benefits of reduced content are twofold. First, these smaller files require less bandwidth for upload to FWS and therefore should upload quicker. Second, the server-side parser can process the filing quicker since all the GUI fluff has been removed from the reduced file.

This specification, by itself, is not sufficient to generate correct reduced content filings. We assume the reader is already familiar with the various SEC form types, filing act requirements, and SEC syntax rules. The following documents provide additional filing information and provide a resource for the XFDL specification.

• EDGAR 8.0 Filers Manual may be obtained from http://www.sec.gov. Chapter 5 specifically addresses the forms templates and data fields on the forms. [Webmasters note: EDGAR 8.0 Filers Manual will be posted on September 17, 2001.]
• XFDL Forms Specification may be obtained from http://www.w3.org/TR/1998/NOTE-XFDL-19980902

NOTE: Although we used the PureEdge product suite to develop the EDGAR electronic forms, PureEdge did not participate in this process. Do NOT contact PureEdge for information specific to the SEC form templates or this reduced content specification.

2. Organization of this Specification

The remaining sections of this specification provide the framework for successfully constructing a "reduced content" XFDL filing.

Section 3 provides an overview of the six XFDL templates to which this specification applies.

Section 4 provides general rules concerning the XFDL file being created.

Section 5 details the specific rules for each type of XFDL node used to pass data to the EDGAR Server.

Section 6 describes a means of verifying that the structure of an XFDL file is correct. For example, you can use the described technique to find a missing end tag.

Section 7 describes the many appendices to this specification and how to use them. These appendices provide all the details concerning how to create a specific SEC form, which templates create which form types, and the set of valid values for several input fields.

Section 8 provides several examples (at least one for each template) of reduced content filings.

3. XFDL Templates

The six XFDL templates to which this Reduced Content Specification apply are:

Template6 lets a filer collect multiple XFDL files created with the other five templates into a single bundle for a BULK submission. The only constraint here is that one BULK submission cannot include another BULK submission.

The controlled master versions of these templates that are available for download on the Filer Web site are saved in a PureEdge proprietary compressed file format. As such, they cannot be viewed or manipulated without the PureEdge Viewer. All submission files created via the Viewer are also saved in this same proprietary format.

The master templates are saved in this compressed format to improve file upload and download efficiency and as a measure of security.

XFDL forms are XML documents; the form definition is encoded using XML elements and attributes. The XFDL specification uses DTD notation to express nesting and sequence relationships between the elements and attributes; while the constraints on element contents and attribute values are given in the BNF notation found in the XML specification.

4. Reduced Content File Format

1. A reduced content XFDL submission file must be ASCII text in either DOS or UNIX format.
   
   That is, lines must be terminated with either a carriage return and line feed (\r\n) or with just a line feed (\n). The PureEdge API does not support the Macintosh format of just a carriage return (\r).
    
2. The PureEdge compression methodology is proprietary, so you can only compress a reduced content filing if you have access to the PureEdge Designer product.
   
   If you use the Designer to compress a submission, use ASCII compression rather than binary.
    
3. A reduced content file cannot be digitally signed.
    
4. A reduced content file name must end with either an .xfd or .frm extension.
   
   We recommend the .xfd extension, since several commercial software products use the .frm file type (for example, Visual Basic). Under Windows, a user may find the .frm file type already registered with another software program on his workstation.
    
5. The names of attached document files must follow internal EDGAR file naming convention. The file naming convention is:
    
   • File names no longer than 32 characters, including the file extension.
   • Valid characters are lowercase letters, digits 0-9, up to one underscore, up to one hyphen, and up to one period.
   • First character must be a letter.
   • Spaces are not allowed.
   • File name must have a file type extension.
   • File extension must be .txt, .htm, .pdf, .fil, .jpg, or .gif
      
6. Module and segment names referenced on page 4 of submissions must follow the internal EDGAR module/segment naming convention. The module/segment naming convention is:
   
   
   • Module/segment name must be no longer than 15 characters.
   • Valid characters are uppercase letters, digits 0-9, underscores, or hyphens (not periods).
   • First character must be a letter.
   • Spaces are not allowed.
      
7. Date values can be specified in one of these formats:
   
   

   MM/DD/YY		10/10/01
   MM/DD/YYYY		10/10/2001
   MM-DD-YY		10-10-01
   MM-DD-YYYY		10-10-2001
   MMM DD, YY		October 10, 01
   MMM DD, YYYY		October 10, 2001

5. Reduced Content XFDL Elements

An XFDL scope identifier, or sid, uniquely identifies an element within the scope of its logical parent. An XFDL element may have a sid attribute which uniquely identifies the form within a system of forms in a large deployment. Each page element must have a sid attribute that uniquely identifies the page within the surrounding XFDL form element. An item element must have a sid attribute that uniquely identifies the item within the surrounding page element. The minimal set of XFDL elements required to create reduced content submissions are discussed in the following sections. Other XFDL elements used in the master EDGAR XFDL templates, such as those for GUI rendering, are not discussed.

NOTE: The following reduced content element definitions use example data to illustrate typical values. Remember to change these values as required when creating a reduced content filing. Valid values are provided where only a few are possible.

5.1 Version Nodes

Two version tags must be included as the first two lines of each submission. The current valid values are:

<?xml version="1.0"?>
<XFDL version="4.3.0">

5.2 End XFDL Node

To properly end a submission, this tag must be the last line of the submission.

</XFDL>

5.3 Page Nodes

The <page> nodes are critical to EDGAR server-side processing and must be included. These pages contain the following data:

Page	Description	Template1	Template2	Template3	Template4	Template5	Template6
1	Header Data	x	x	x	x	x
2	Enclosed Documents	x	x	x	x	x	x
3	Notification Data	x	x	x	x	x
4	Module/Segment References	x	x	x	x
5	Offset Payments	x	x
6	Offering Data	x	x
7	Sales Shares Data	x

The rules governing the <page> nodes are:

1. Valid values for a <page> sid are "PAGE1", "PAGE2", "PAGE3", "PAGE4", "PAGE5", "PAGE6", and "PAGE7".
    
2. Pages must appear in sequential order, starting at PAGE1.
    
3. All nodes except the two version nodes described in section 7.1 must be bounded by <page sid= > </page> nodes.
    
4. You may completely exclude a page if none of the fields on that page contain any data.
   
   For example, if an S-1 submission has no module or segment references, the reduced content file does not need to contain a PAGE4.

5.4 Valid Scope (Node) Identifiers

This section lists the valid node, or scope (sid), identifiers as of EDGAR version 8.0. Only these sid's may be included in a submission. If any other sid is detected during processing, the EDGAR Receipt server will suspend the submission.

EDGAR 8.0 does not support some of the sid's used in the Version 7.0 and version 7.5 PureEdge templates

Appendix II provides a more detailed breakout of the valid sid's by Template and Page. The tables provided here are just alphabetical listings of the valid 8.0 sid's and the obsolete 7.0 and 7.5 sid's.

5.4.1 Valid Edgar 8.0 Scope Identifiers (sid's)

5.4.2 Obsolete Scope Identifiers from 7.0 and 7.5

The EDGAR 8.0 Receipt server will suspend a submission that contains any of these sid's.

5.5 Submission Data Nodes

All data related to the submission is stored in five types of XFDL nodes. These five node types are:

The rules for specifying one of these nodes are:

1. The server-side parser is case-sensitive. You must use the sid names and valid values prescribed in the appendices and the attached master templates when constructing these nodes.
    
2. A node must have a unique sid and a <value>.
    
     <field sid="SubTable_submissionType_"><value>S-1</value></field>
    
3. The <value> tag is optional if a field has no value. However, we suggest including the <value></value> tag for consistency.
    
4. A <value> node may only contain a single data item.
    
5. The sid for these nodes must be of the form:
    
   className_tagName_recordNumber
    
   The className and tagName portions must exactly match the names provided in the Appendices and the underscores must always be present. Append the recordNumber to a sid only when you need to report multiple values for a particular category of data, e.g., SRO values. The recordNumber is simply an increasing integer number used to uniquely identify the multiple values for a particular field. The first instance of any field does not get a recordNumber; zero is implied. The second instance gets a recordNumber of 1, the third instance a recordNumber of 2, and so on. A couple of examples will make this clear.
    
   For a field that has only a single value, such as the Submission Type combobox, the sid for the node will not have a recordNumber component. For this example, the node sid (field name) will be:
    
   SubTable_submissionType_   (the trailing underscore must be present)
    
   To report multiple values for a particular field, use the recordNumber to differentiate these values. For example, to report three SRO values, you would create these three node sid's:
    
   SubSro_sroId_
   SubSro_sroId_1
   SubSro_sroId_2
    
   
6. White space between nodes is ignored. These two specifications are equivalent.
   
   <field sid="SubTable_submissionType_"><value>S-1</value></field>
   
   <field sid="SubTable_submissionType_">
           <value>S-1</value>
   </field>
    
7. The order of the nodes within a page only matters in two cases.
    
   1. For an enclosed document in Templates 1, 2, 3, 4, and 6, SubDocument_conformedName_ must precede the document's <data> node.
       
   2. For an enclosed document in Template 5,
      SubModSeg_ModSegFileName_ must precede the document's <data> node.
       
8. The ampersand (&) and left angle bracket (<) are not permitted in character data content of XML elements. If there is a need to include these characters in character data, such as a value, you must enclose the character data in a CDATA section. For example, a value for a form name which contains an embedded ampersand would need to be expressed as:
   
   <value><![CDATA[EX-99.2I O&D BENEFTS]]></value>

5.6 Field Nodes

The only information required for a <field> node is a valid name and <value>. Appendix I lists all valid text field names.

<field sid="SubFiler_filerId_">
        <value>0000000129</value>
</field>

5.7 Checkbox Nodes

The only information required for a <check> node is a valid name and a <value>. Appendix I lists all valid checkbox names. Recommend always including a <value> tag for consistency. This prevents a scenario where a checkbox is mandatory but the user provides no value. The only valid values for a <check> node are "on" and "off".

<check sid="SubFlag_confirmingCopyFlag_">
        <value>on</value>
</check>

5.8 Radio Button Nodes

The minimum information required for a <radio> node is a valid name and <value>. Valid values are "on" and "off". The only radio button in any of the templates is used to indicate if the submission is LIVE or TEST. A value of "on" means it is a LIVE submission. A value of "off" means it is a TEST submission. Recommend always including a <value> tag for consistency. The only valid values for a <radio> node are "on" and "off".

<radio sid=" SubTable_live_">
        <value>on</value>
</radio>

5.9 POPUP NODES

The only information required for a <popup> node is a valid name and <value>. Appendices IX - XIII list the valid values for all <popup> nodes.

<popup sid="SubFiler_formType_">
        <value>S-1</value>
</popup>

5.10 Combobox Nodes

The only information required for a <combobox> node is a valid name and <value>. Appendices IX - XIII list the valid values for all <combobox> nodes.

<combobox sid="SubTable_submissionType_">
        <value>S-4EF/A</value>
</combobox>

5.11 Data Nodes - (Enclosed Documents)

Each document enclosed on Page 2 of the submission must have a <data> node of the following format:

<data sid="data1">

<filename>cover.txt</filename>

<mimedata>

VGhpcyBpcyBteSBjb3ZlciBsZXR0ZXIuDQpJdCBpcyBmb3IgYS

B0ZXN0IG9mIGEgY29ycmVzcG9uZGVuY2Ugc3VibWlzc2lvbi4N

Cg0KSSBob3BlIHRoaXMgd29ya3Mu

</mimedata>

</data>

You may supply whatever you want as the sid for a data node, just as long as it is a valid XML name and it is unique to PAGE2 of the submission.

The <filename> is really the key item when defining a data node. It is the link to the SubDocument_conformedName_ or SubModSeg_ModSegFileName_ field that corresponds to this data node.

The <mimedata> block contains the MIME encoded document. A document must be encoded before you put it into the submission file. The MIME algorithm used by the PureEdge product is not proprietary, so any standard 64-character set based MIME encoding algorithm can be used.

Section 8.7 of this specification is a sample CORRESPONDENCE submission with two enclosed documents. Section 8.9 is a sample BULK submission with three enclosed documents. In the case of bulk submissions using Template6, each enclosed MIME document is a complete XFDL submission file.

6. Verifying Reduced Content Structure

To verify that a Reduced Content file does not contain any structural errors, you can simply take advantage of the fact that the file is really XML. To verify the content:

1. Rename the file, giving it an .xml suffix.
    
2. Open the file in your browser.
    
3. If the file contains structural errors, the browser will give you the offending line numbers.

7. How to use Appendices

Click Here To Download the Appendices (MS Excel spreadsheet: approx. 155 KB)

Changes to Reduced Content Specification: Changes to the EDGAR 8.0 software have necessitated that minor changes be made to the associated reduced content specification appendices. The changes are red-lined in the attached APPENDICES8.0 document and are also explained in the attached READ-ME (CHANGES) document. The body of the reduced content specification has not been altered. All developers that use this specification will need to download the file update to ensure any development work is consistent with the aforementioned changes.

This specification contains several appendices that define what is required for each electronic SEC form. These appendices are:

1. Appendix I is a mapping of all EDGAR form types to the submission templates.
    
2. Appendix II is a complete list of all the unique sid's used in the six submission templates.
   
   You should never have a sid that is not in this list in a reduced content file. This list also provides, for each sid, the node type (field, popup, combobox, check, or radio), a mapping of the node to the template(s) that use it, and whether the node is repeatable.
    
3. Appendices III - VIII show which PAGE1 header fields, or sid's, are applicable to each form type for Templates 1 thru 6.
   
   

   Appendix III	Template1 form-type field dependencies
   Appendix IV	Template2 form-type field dependencies
   Appendix V	Template3 form-type field dependencies
   Appendix VI	Template4 form-type field dependencies
   Appendix VII	Template5 form-type field dependencies
   Appendix VIII	Template6 form-type field dependencies

   
   The following table explains the numeric codes that appear in the matrices in these six appendices.
   
   

   Code	Status
   1	Required
   2	Conditionally Required (if any field in group has a value, all fields in the group must have a value)
   3	When specifying a SubOffering entry, both the securityName and aggregatePrice are Required. The offeringShares and offeringAmountPerShare fields are optional.
   4	Optional
   5	Required for a confirming copy submission (i.e. for electronic submissions which are copies of official filings made in paper under a hardship exemption)

   
   The fields in Appendix II that have one of these numbers assigned are not included in Appendices III - VIII. These appendices only indicate which of a template's conditional fields are applicable to each form type handled by the template.
    
   To determine the complete set of valid sid's for a given form type, you must refer to both Appendix II as well as one of these template-specific Appendices.
    
4. Appendices IX - XIII show the valid values for the <field>, <combobox>, and <popup> nodes that are limited to a set of prescribed values.
   
   

   Appendix IX	Template1 choice lists
   Appendix X	Template2 choice lists
   Appendix XI	Template3 choice lists
   Appendix XII	Template4 choice lists
   Appendix XIII	Template5 choice lists

Click Here To Continue Reading the Specification (go to "8. Sample Forms")

http://www.sec.gov/info/edgar/ednews/edgarxfdl80.htm