U.S. Securities & Exchange Commission
SEC Seal
Home | Previous Page
U.S. Securities and Exchange Commission

EDGAR Information:
Reduced Content XFDL Specification

Notice: Reduced Content Specification Change — In this DRAFT of the reduced content specification, we updated EDGARLink submission template #2 to disallow submission form types 3, 3/A, 4, 4/A, 5 and 5/A. These forms will need to be filed via an OnlineForms website, that is new for Release 8.5 — See Appendices Section.

Release Notes

This Release introduces a minor update to submission Template 2 that is based on recent SEC requests and rulemaking activities. EDGAR 8.5 supports backward compatibility with the 8.4.s templates as long as the reporting requirements for specific form types have not changed. EDGAR 8.5 server software supports all of the field identifiers that were valid in the 8.4.s version of the PureEdge templates.

Changes By Template

The following change is called out in the appendices. Please refer there for details.

Template 2

1. Ownership submission types are no longer allowed in the SubTable_submissionType_ field.

a. 3, 3/A, 4, 4/A, 5, 5/A

Note: As of Release 8.5, the above listed ownership submission types are submitted electronically via OnlineForms. Please refer to the Reduced Content XML Filing Specification for more information on assembling these submission types.

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.

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:

NicknameFilename on FWSPurpose
Template1Subtemplate1.xfd107 submission types
Template2Subtemplate2.xfd122 submission types
Template3Subtemplate3.xfd162 submission types
Template4Subtemplate4.xfdCORRESPONDENCE submission
Template5Subtemplate5.xfdMODULE or SEGMENT submission
Template6Subtemplate6.xfdBULK submission

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   0/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="5.0.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:

PageDescriptionTemplate1Template2 Template3Template4Template5Template6

1Header Dataxxxxx 
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 5.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.5. 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.

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.5 sid's.

5.4.1 VALID EDGAR 8.5 SCOPE IDENTIFIERS (sid's)

ModSegReferenceData_ccc_ SubInternet_internetAddress_
ModSegReferenceData_cik_ SubItem_itemId_
ModSegReferenceData_documentType_ SubModSeg_ModSegDescription_
ModSegReferenceData_modOrSegFlag_ SubModSeg_ModSegFileName_
ModSegReferenceData_nickName_ SubModSeg_ModSegMasterCIK_
SubCompany_fileNumber_ SubModSeg_ModSegName_
SubCompany_filerId_ SubModSeg_ModSegType_
SubCompany_filerName_ SubOffering_aggregatePrice_
SubCompany_irsNumber_ SubOffering_offeringAmountPerShare_
SubContact_contactName_ SubOffering_offeringShares_
SubContact_contactPhoneNumber_ SubOffering_securityName_
SubCoreg_fileNumber_ SubOffset_offsetAmount_
SubCoreg_filerCcc_ SubOffset_offsetFileNumber_
SubCoreg_filerId_ SubOffset_offsetFilingDate_
SubCoreg_formType_ SubOffset_offsetForm_
SubDate_effectivenessDateOfReport_ SubOffset_offsetId_
SubDocument_conformedDocumentType_ SubPayor_payorCcc_
SubDocument_conformedName_ SubPayor_payorId_
SubDocument_description_ SubRef429_fileNumber_
SubFee_feeAmount_ SubSalesShares_redeemedValue_
SubFee_feeBasis_ SubSalesShares_salesProceeds_
SubFee_paymentMethod_ SubSalesShares_series_
SubFiler_fileNumber_ SubSro_sroId_
SubFiler_filerCcc_ SubTable_act_
SubFiler_filerId_ SubTable_depository_
SubFiler_filerRelationship_ SubTable_fiscalYear_
SubFiler_formType_ SubTable_live_
SubFlag_confirmingCopyFlag_ SubTable_periodOfReport_
SubFlag_delayingAmendmentFlag_ SubTable_reference462b_
SubFlag_overrideInternetFlag_ SubTable_submissionType_
SubFlag_returnCopyFlag_  
SubFlag_serialFlag_  
SubGlobal_enclosedFileCount_  
SubGroup_groupName_  

5.5 Submission Data Nodes

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

<field>Text Field in the Viewer
<check>Checkbox in the Viewer
<radio>Radio Button in the Viewer
<popup>Popup in the Viewer
<combobox>  Combo Box in the Viewer

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>.
     
    <combobox sid="SubTable_submissionType_"><value>S-1</value> </combobox>
     
  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.
       
    3. 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 II 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 II 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 CORRESP submission with one enclosed document. 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

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 IIITemplate1 form-type field dependencies
    Appendix IVTemplate2 form-type field dependencies
    Appendix VTemplate3 form-type field dependencies
    Appendix VITemplate4 form-type field dependencies
    Appendix VIITemplate5 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 IXTemplate1 choice lists
    Appendix XTemplate2 choice lists
    Appendix XITemplate3 choice lists
    Appendix XIITemplate4 choice lists
    Appendix XIIITemplate5 choice lists

*
Appendices

8. Sample Forms


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

 

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


Modified: 02/20/2003