|Template 1||Template 2||Template 3|
|Various 1933 Securities Act Registration Statements||Various Investment Company Submission Types||Annual, Quarterly, and Periodic Reports|
|AW WD||Williams Act Submission Types||40-F|
|Registration of Securities by Certain Investment Companies Pursuant to Rule 24f-2||CB/A||8-K12B|
|Submissions Pursuant to the Trust Indenture Act||F-N||8-K12B/A|
|Registration Statements for Foreign Issuers||SC13E4F/A||1934 Securities Exchange Act Registration Statements|
|F-4EF||Miscellaneous 1933 Securities Act Submission Types||40FR12G|
|F-7/A||Ownership Submissions Pursuant to Section 16 or Rule 144|
|F-7 POS||Development Bank Submission Types|
|Template 1||Template 2||Template 3|
|Various 1933 Securities Act Registration Statements||
1934 Securities Exchange Act Proxy Materials and Information Statements Filed Pursuant to Section 14
Annual, Quarterly, and Periodic Reports
Williams Act Submission Types
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.
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.
The six XFDL templates to which this Reduced Content Specification apply are:
|Nickname||Filename on FWS||Purpose|
|Template1||Subtemplate1.xfd||107 submission types|
|Template2||Subtemplate2.xfd||128 submission types|
|Template3||Subtemplate3.xfd||148 submission types|
|Template5||Subtemplate5.xfd||MODULE or SEGMENT 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.
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.
Two version tags must be included as the first two lines of each submission. The current valid values are:
To properly end a submission, this tag must be the last line of the submission.
The <page> nodes are critical to EDGAR server-side processing and must be included. These pages contain the following data:
|7||Sales Shares Data||x|
The rules governing the <page> nodes are:
This section lists the valid node, or scope (sid), identifiers as of EDGAR version 8.2. 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.2 sid's.
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:
<value><![CDATA[EX-99.2I O&D BENEFTS]]></value>
The only information required for a <field> node is a valid name and <value>. Appendix I lists all valid text field names.
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".
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_">
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.
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.
Each document enclosed on Page 2 of the submission must have a <data> node of the following format:
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 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.
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:
|Click Here To Download the Appendices
(MS Excel spreadsheet: approx. 188 KB)
Changes to Reduced Content Specification: Changes to the EDGAR 8.2 software have necessitated that changes be made to the associated reduced content specification appendices. The changes are red-lined (identified by strikethrough and bold, italicized fonts) in the attached xfdlappendix82.xls document. 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:
|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|
|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.|
|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)|
|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")
|Home | Previous Page||