April 15, 1999
Jonathan G. Katz
Secretary
Securities and Exchange Commission
405 Fifth Street, N.W.
Washington, D.C. 20549-0609
Subject: File Number S7-9-99 – Comments on SEC Proposed EDGAR II Rules
Dear Mr. Katz:
Merrill Corporation is very excited about the modernization of EDGAR and the transition to Internet technology. We are pleased to work with the SEC during this transition by learning more and by helping to guide decisions and development. Merrill is scaling up our existing services to produce SEC compliant HTML and PDF documents as part of our EDGAR Advantage services. If you need further information or assistance, please contact us at (800) 688-1933. Below are the comments and recommendations we have regarding the proposed EDGAR II rules.
Since there isn't an easy solution for filers to create SEC-compliant HTML, the SEC should continue to allow ASCII filings indefinitely for all submission types. The inconvenience will not be limited to the initial learning curve, but will also include extra labor with each filing.
Since the submission header isn't disseminated, and assuming EDGARLink will appropriately handle any tag requirements for the submission header, there doesn't seem to be any advantage to the filer or to the investing public to use XML.
Since PDFs are not required, they shouldn't be referenced in the exhibit index. In preparing the filing, it may be a last-minute decision to include or exclude the PDFs. It will be an unnecessary inconvenience to modify the official copy index if it became clear that there would be inadequate time to prepare the appropriate PDFs.
It doesn't seem like there is a practical way to limit size on PDF documents, particularly since the PDF document is the best way to represent the printed document for dissemination. To address potential storage concerns, it seems more appropriate to limit elements within PDF documents. For example, limit the resolution of graphics, limit the embedding of fonts, and encourage font subsetting where appropriate.
Filing agents will meet the needs of their customers. Initially we expect HTML acceptance to be slow. Filers will be very tentative to use HTML for time-sensitive documents (transactional). There is no reason for filers to take any additional risk with a less familiar format, particularly one that requires additional labor to prepare. Alternatively, PDFs may be more readily accepted. PDFs are easier to prepare and provide much more perceived value since they reflect the printed document. If the SEC places a limit on the file size of PDF documents, acceptance of PDF by the filing public will be slower since the limitation will complicate the process creation. The casual investor will probably prefer the PDF, since it reflects the printed document including all graphic images. The serious investor and more technical audience will prefer the HTML, due to speed and searchability.
It is not stated in the rules whether PDFs included in the filing will be posted on the SEC website as PDFs or as Uuencoded PDFs. Unless PDFs are posted as PDFs, they will be of no value to the average investor. The average investor will not know how to decode a uuencoded document.
One of the advantages of having ASCII or HTML is searchability. If the SEC allows information contained in tables, charts, text or other required content to be represented as a graphic image, the searchability will be compromised.
There doesn't seem to be a consistent and reasonable approach to limit the number of graphics per document or per file. The SEC should provide suggestions and guidelines about how to minimize graphic element size. It may be reasonable to limit file size of each individual graphic file.
Yes, if the graphic has to be created for the printed copy, it should be consistent in the official copy.
Hypertext links should be allowed to other documents within a filing. Links should be allowed between other documents already filed and accepted with the SEC to be incorporated by reference.
No, the filers should not be required to use client side certificates. Secure sockets provide adequate security.
The SEC should specify a limited set of browsers that filers should use to provide an acceptable appearance of the HTML documents. The SEC should have a disclaimer that states these browser standards, and further disclaims printing of SEC filings. Trying to set a standard screen size provides no value because a user may not have their browser set as full screen, and may have the default font size different from the default that filers intended. If either of these cases is true, then picking a standard screen size will be irrelevant. Width restrictions make no sense because they would be based on an assumption about what typical settings the investor public would have or be willing to adhere to.
By restricting the tag set, the burden is greater on the filing community. The ability to use products off the shelf is minimized or eliminated. It requires the person preparing the filing not only to know and understand HTML 3.2, but further they have to understand the SEC-restricted tag set. The usability of these filings doesn't increase over EDGAR/ASCII. The visual appeal is improved, but not necessarily representative of the printed document. The typical filer may not understand or readily accept the differences from the print document or the increased amount of labor required to more closely resemble the print document.
There is no reason for the SEC to continue accepting diskettes.
It seems unnecessary that the SEC would allow PDF copies of correspondence and cover letters since these will not be disseminated. Confidential filings should, however should be allowed to be sent electronically and marked by a special tag or Form type so they are not disseminated.
The UIT textual N-SARs should be acceptable in either ASCII or HTML.
The issue of external links and inactive URL references is the same. The content variability and risk are the same. Given the direction of technology, it will become more and more of an issue to restrict it going forward. If links are not restricted, the SEC may need to provide disclaimers stating that external linked documents are not part of the official filing.
Required signatures should be allowed in script when graphics are permitted.
A. Nested tables
One of the advantages of HTML is to provide a better visual display of the document. By restricting the use of nested tables, you are eliminating one of the tools to create a visual representation.
B. <ISINDEX>
This will put out a Prompt and an answer box. This tag really is only relevant with the Base URL tag which when the user puts in text and presses return the string is sent to the server identified by the base URL.
| a) | For document-specific navigation toolbars or menus. |
| b) | To control how collections of HTML files are rendered into printed documents. |
| c) | For linking associated resources such as style sheets and scripts. |
| d) | To provide alternative forms of the current document. |
| a) | HREF - Points to the URL of the other document. Since we cannot link outside of the current document this is assumed to be not legal. |
| b) | REL - Defines the relationship between the current document and the other document. Since we can't reference other documents this would be irrelevant. |
| c) | REV - This is the opposite of the REL attribute and defines the relationship between the other document and the current document. Since we can't reference other documents this would be irrelevant. |
| d) | TYPE - Specifies the type and parameters for a linked style sheet. Since we can't reference other documents this would be irrelevant. |
What is the purpose of this tag if we can't link out of our current document?
D. <META>
F. Character Entities
Are there any restrictions regarding the use of Entities? The example tag that you have listed, <~<> will display <~<>. Did you mean < which would display a < symbol. Please publish a list identifying which character entities can be used.
G. <LISTING>, <XMP>, and <PLAINTEXT>
These elements have been declared obsolete. Some HTML elements are not permitted inside of them and the results can be unpleasant. Because they have been declared obsolete, browsers are not required to support them any longer. This could make documents filed today look different in the future. It would be better to only allow <PRE> tags.
H. <DFN>
We could not find any reference to this tag.
I. Acceptable Validation Attributes
Could you make available all of the attributes for each HTML tag that is acceptable by the validation program?
J. Validation Software Specifications
Could you make the SEC validation software or the specifications that it uses available for everyone to review? This would help prevent missed filings.
K. <!DOCTYPE>
Every conforming HTML 3.2 document must start with the <!DOCTYPE> declaration that is needed to distinguish HTML 3.2 from other versions of HTML. An example of the tag is: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">. Since the SEC is using a Subset of 3.2 HTML what does that mean for this tag?
The Mailto: attribute for the <A> tag is not specifically mentioned, depending on how the users browser and MIME types are configured, "mailto:" will launch the email application. While technically this is not an external reference, does it fall under the executable code prohibition? An example of this is provided below:
There is no mention of color in the rules. Can we use all colors or are there some reserved colors that cannot be used?
Thank you for giving us an opportunity to comment on the SEC proposed EDGAR II rules and provide more efficient services for the registrants and law firms we work with every day.
Regards,
Kris Wiklund
EDGAR Advantage Operations Manager
Merrill Corporation
kris.wiklund@merrillcorp.com
Tom Staloch
Director of Software Development
Merrill Corporation
tom.staloch@merrillcorp.com