| Comments of Joel Aufrecht, Partes Corporation |
Section 23(a)(2) of the Exchange Act requires us, in adopting rules under the Exchange Act, to consider the anti-competitive effects of any rules we adopt thereunder. Furthermore, Sections [ ] require us, when engaging in rulemaking, and considering or determining whether an action is necessary or appropriate in the public interest, to consider whether the action will promote efficiency, competition, and capital formation.
| 1) We request comment on whether we should continue to accept all EDGAR submissions in ASCII, or whether, in the future, we should require submission of all or some documents in HTML. |
A single format offers long term efficiency for filers, disseminators, and end users. Transition periods will be necessary to allow filers to catch up; disseminators have no choice but to stay current. The system should schedule and enforce elimination of older formats at about the same pace as the acceptance of new. Otherwise, the proliferation of forms will degrade the value of the EDGAR standard.
a) If you think we should require some or all submissions in HTML, please state when HTML should become mandatory and specify the submissions we should require in HTML format.
The HTML format has advantages over the current SGML only if it is carefully defined and rigorously validated. If definition and validation occur, HTML should be used as soon as possible. If not, HTML will degrade end users' ability to access filings reliably, and should not be introduced.
i) How soon will individuals, companies, filing agents and training agents begin using HTML?
Partes expects to be ready to offer HTML filings to customers by the scheduled May 24 introduction date.
b) We request comments and data on the impact of converting to HTML from ASCII. i) Are there one-time or ongoing extra costs?c) We request comment on the use of eXtensible Markup Language ("XML"), particularly for EDGAR submission header tags.ii) Will the conversion affect all filers equally, e.g., small business issuers or frequent issuers of securities?
The original SGML format offers tremendous value to EDGAR users because its tagging is semantic - it unambiguously sets the meaning of tagged data. Conversely, SGML tagging is visually unappealing.Since HTML is visual markup language, it offers much more attractive formatting power. It can also damage the value of the data by increasing semantic ambiguity, especially when HTML features are used inappropriately for visual effect. For example, the <SECTION> tag in the SGML DTD is very useful in constructing a table of contents for a filing. The corresponding <H1> tag in HTML can be used in the same fashion. It can also be used to set large font sizes in document bodies or in table cells. A filer using <H1> in this fashion prevents the derivation of a table of contents from the filing. Similarly, frames, DHTML, and other visual presentation methods are not useful in identifying content within a filing.
XML offers the best compromise between visual and semantic tagging. A rigorous XML DTD expanded from the current SGML DTD would preserve and extend the existing value in the EDGAR system while also providing filers with means to present visual enhancements. Filers could use a standard XSL sheet or custom sheets to display their XML-tagged document with the same visual flexibility and power as HTML, without damaging the value of semantic tags.
However, any markup system which is not validated is of minimal value. A system in which SGML, HTML, and XML were all permitted in parallel would also offer very little value to users.
| 2) We request comment on our proposal to allow unofficial PDF copies of official filings. |
Partes opposes the use of PDF in EDGAR distribution for several reasons. PDF is optimized for visual representation of content, not for access to the text or numbers within. End users find value in standardized presentation of data and in unadorned, straightforward information; enhanced presentation is better kept to the annual report, which could simply be hyperlinked from the filing header. PDF is a proprietary format, unlike HTML, SGML, or XML, and this limits the accessibility and flexibility of the standard. There are also technical concerns regarding security and bandwidth, both for disseminators and for end users.
a) Should the unofficial PDF copy contain a legend or disclaimer that it is not the official filing?
Yes.
i) How else could we alert viewers to the unofficial status of the PDF copy? 3) We request comment on the circumstances and manner in which we might limit file size and the type of graphic and image materials. |
Multiple filing formats reduce the value of the EDGAR system, which is derived from standardization and consistency. A rigorously validated XML DTD, incorporating the best elements of both EDGAR's SGML DTD and HTML 3.2 formatting, is the most effective and accessible format for EDGAR dissemination.
a) For example, should we propose a limitation on the allowed size of each file or group of files, including graphic and image files, and provide EDGAR Filer Manual instructions on ways to minimize file size?
If graphic files are allowed, a limit of no more than two to three times the size of the ASCII filing would adequately address volume concerns.
4) We request comment on whether, following the HTML implementation period, we should allow external hypertext links.i) Should we limit the total number of files that include graphic and/or image material?b) We are considering whether, once the HTML implementation period is over, if we permit graphic and image material in HTML documents, we should require graphic and image material to be included in HTML documents under some circumstances. Should we propose that, when our rules require information to be in graphic form, filers using HTML be required to present the graphic, rather than merely giving the data, in the HTML document?i) Or, should the presentation of graphic and image material continue to be optional to alleviate the burden on filers who do not currently have the resources to prepare graphic and image material? |
Partes strongly favors this approach as a means to introduce diverse content without compromising the benefits of the EDGAR system.
a) For example, should we allow links from within a filing to previously filed documents that are incorporated by reference?
Existing filings should be referred to by Accession number rather than hyperlink; then, each provider can create hyperlinks or otherwise interpret the unique address (the accession number) as appropriate for the delivery channel.
| 5) We initially propose to maximize the likelihood of consistent document appearance across different browsers by specifying HTML 3.2 as the required standard for HTML documents. We request comment on our selection of a standard. |
HTML 3.2 is a good standard for readability enhancements, provided that (a) all filings are validated for compliance and (b) only a carefully selected subset of HTML is allowed, excluding those tags that introduce complications and do not benefit accessibility.
a) We also request comment on whether we should specify a standard screen size (e.g., 800 by 600 pixels) for HTML document preparers to use to assure that documents will fit most viewers' browser screens and will be printable on most printers.
800 x 600 is good.
b) In addition to using HTML 3.2 as the standard, we also propose to adopt a set of permissible HTML 3.2 tags for use in HTML documents during the HTML implementation period. These permissible tags allow for most HTML 3.2 formatting capability while eliminating active content and certain classes of hypertext links. c) The tentative list of these tags, which will be included in the EDGAR Filer Manual and updated from time to time, appears in Appendix A to this release. In general, the EDGAR system will suspend filings if they contain tags that are not permitted. We request comment on the proposed tag set, including whether we should permit, require, or prohibit any particular tag.
[See following.]
i) In particular, we call attention to the fact that we do not plan to allow tables within tables ("nested tables"). This is because users of EDGAR information may find it difficult to locate and use information in documents with nested tables.
Two-dimensional tables with strict row and column definitions represent the lowest common denominator for tabular data, and offer the most value to the most end-users. Nested tables are frequently used on web pages to serve formatting and presentation needs, but are not necessary or even compatible with tabular presentation. SPAN attributes within row and column tags can also be detrimental to clear presentation of tabular data.
d) We envision proposing certain restrictions on the presentation and grouping of HTML files within a single HTML document to promote complete, readable, and accurate printing by our staff and web users. We request comment on technical approaches to facilitate printing of HTML documents, including file ordering and width restrictions.
The HTML standard has proven very limited in the area of consistent, reproducible printing.
| 6) We believe that these advances will ease the burden upon filers by enabling them to submit documents to the EDGAR system in a format similar to the documents they present to the public and to investors. In addition, we believe that these advances will maintain the ability for the public to view, process and analyze the content of filings. We request comment on whether the changes we propose will achieve these goals. |
PDF filings will hinder the ability for the public to process and analyze content. Unvalidated HTML will hinder viewing, processing, and analyzing.A public domain validator that filers and filing agents could use to test submissions prior to submission would be very valuable.
a) We also request comment on what other steps we can take to ease filer burden further while maintaining the usability of the filings.7) We also request comment on whether, following HTML implementation, we should continue to prohibit the submission of all executable code. |
Yes.
8) We encourage commenters to identify any other costs or benefits associated with the rule proposals that have not been addressed.
a) In particular, please identify any costs or benefits associated with the rule proposals relating toi) the contents of an "official filing," |
An official filing should always be limited to textual and tabular representation of data with controlled and validated structure and formatting. This represents the lowest cost and highest value for EDGAR dissemination to the public.
ii) impermissible types of code and content,
The use of multiple official formats in parallel introduces high costs to all users.
iii) hypertext links to external documents or web sites,
These links are an extremely cost-effective and valuable means to handle dissemination of non-standard data outside of official channels.
iv) variations in the appearance of an "official filing" that is accessed through different browsers, v) and any impact that the rule proposals may have on the ease of locating and using EDGAR data.
PDF and non-validated ASCII threaten the ability of end users to reliably locate and use EDGAR data.
Appendix A -- Acceptable Tags For Html Documents
Acceptable HTML 3.2 Tags -- Document Header
Non-Format Tags Definition
<HTML> Identifies text as HTML document
<!--> Comment does not appear in browser, only in HTML
source
<A> Anchor/Hyperlink
[NOTE: For the attribute HREF, external references are
not supported; however, Bookmark (internal) references
will be supported]
|
How will external references be detected? One method would be to require all instances of "HREF=" to have "#" as the next character.
<BODY> Signifies the body of the HTML document
[NOTE: The BACKGROUND attribute is not supported for
this tag]
|
The BGCOLOR, TEXT, and BGPROPERTIES attributes should also be forbidden. Altering the color of the text or background can make printing HTML documents more difficult.
<HEAD> Signifies header information for HTML document <ISINDEX> Signifies document is an index for a search engine |
This tag does not offer significant value and may confuse filer intent.
<BASE> Base URL to be used by all links in the document |
This tag should be forbidden; it allows filers to create external hyperlinks.
<LINK> Like a hyperlink, but only contained within header |
This tag should be forbidden; it allows filers to create external hyperlinks.
<META> Extended information to be included in document header
[NOTE: The HTTP-EQUIV attribute is not supported for
this tag]
|
The HTTP-EQUIV attribute is extremely powerful and dangerous; please confirm that documents containing this attribute will be rejected.
<TITLE> Title of document. It is displayed at the top of the
browser
Acceptable HTML 3.2 Tags -- Within Document
Format-Specific Tags Definition
(change the appearance of the text only)
~< Escape Sequences Used to display characters normally
reserved (such as "<") as plain text in the HTML
document
|
The " " tag, especially in tables, can allow filers to create tabular information with non-proportional spaces that are impossible to interpret into two-dimensional data. This tag should be forbidden.
<A> Anchor/Hyperlink
[NOTE: For the attribute HREF, external references are
not supported; however, Bookmark (internal) references
will be supported]
|
Filers should be aware that bookmarks spanning HTML documents within a filing (i.e., the anchor is in one document and the link in another) will not function. See also prior comments on this tag.
<ADDRESS> Address Usually italicized <B> Bold <BLOCKQUOTE> Block Quote Usually indented <BR> Line Break <CITE> Citation <CODE> Code <DIR> Directory List <DL> Definition List Used with <DT> and <DD> <DT> Definition Term <DD> Definition <EM> Emphasized - Like Bold <H1> Heading 1 - Largest <H2> Heading 2 <H3> Heading 3 <H4> Heading 4 <H5> Heading 5 <H6> Heading 6 - Smallest |
Use of the <H#> tags for formatting instead of indication of document structure should be discouraged.
<HR> Horizontal Rule Displays a thin line across the page
separating text
<I> Italic
<KBD> Keyboard Preformatted text
<LI> List Item Used by <DIR>, <MENU>, <OL>, and <UL>
<LISTING> Listing Same as <PRE>
<MENU> Menu List
<OL> Ordered List Includes numbers
<P> Paragraph
<PLAINTEXT> Plain Text
|
This tag may be incompatible with some browsers and should be forbidden.
<PRE> Preformatted Text <SAMP> Sample Uses fixed width font - Like <PRE> <STRIKE> Strikethrough <STRONG> Strong Similar to bold <TT> Teletype Uses fixed width font - Like <PRE> <U> Underlined <UL> Unordered List Bullets only <VAR> Variable Uses fixed width font - Like <PRE> <XMP> Example Same as <PRE> <BIG> Big Text - Increases font size <CAPTION> Caption Can only be used with tables <CENTER> Centers elements between tags <DFN> Definition Like <I> <DIV> Division Helps separate a document into parts <FONT> Allows alteration of font contained within tags |
The COLOR attribute should be forbidden (or limited to RED) as it can interfere with printing. The FACE attribute may be browser-incompatible or otherwise be rendered inconsistently on different systems.
<SMALL> Small Text - Decreases font size <SUB> Subscript <SUP> Superscript |
Footnote markers should be linked with their footnotes via <A NAME> and <A HREF> tags.
<TABLE> Table
[NOTE: No HTML documents with nested <TABLE> tags are
to be accepted or disseminated by EDGAR]
|
The following attributes should be forbidden in TABLE: FRAME, RULES. These tags can prevent unambiguous conversion of HTML tables into simple tabular data. In addition, the attributes BACKGROUND and BGCOLOR, and the three attributes beginning with "BORDER", should be forbidden for all tags, including TABLE, TD, TR, and TH. These tags are browser-specific.
<TD> Table Data or Cell |
The ROWSPAN attribute should be forbidden as it allows ambiguous presentation of data.
<TH> Table Header Displayed in bold
<TR> Table Row
Acceptable Legacy SGML Tags -- Within HTML Documents
Non-Standard Tags Definition
<PAGE> SGML tag for page markers (browsers will ignore this
tag if present)
<R> [NOTE: The <R> tag can also be represented as <R>]
</R> [Second NOTE: the <R> tag will not be publicly
disseminated; it is for SEC use only.]
<SEGMENTS>
</SEGMENTS>
<MODULE>
<NAME>
<CIK>
<CCC>
</MODULE> For incorporation of document text at the Host
[NOTE: These tags will not be publicly disseminated]
|