April 15, 1999

Mr. Jonathan G. Katz, Secretary
Securities and Exchange Commission
450 Fifth Street, N.W.
Washington, D.C. 20549-0609

Dear Mr. Katz:

Please accept this response to the recent request for comments (File No. S7-9-99) regarding the modernization of the EDGAR system.

	Sincerely,
	Jim Gary
	Systems Analyst
	Evaco Financial Printers

 

The test weekends scheduled for Summer '99 will be sufficient to ensure Y2K compliance.

Although we fully expect the majority of our clients to take advantage of filing in HTML format relatively quickly, we do not think HTML submissions should be required until at least 2 years after the end of the HTML implementation period. At that time the question of "HTML vs. ASCII vs. XML (and/or other markup languages in use at that time)" should be revisited. The HTML and XML formats are evolving rapidly. The SEC and filers will not be able to keep up with such a running target. A standard, proven, familiar alternative should be available until HTML is well integrated into the EDGAR system and (hopefully) more stable.

We expect the majority of our clients will take a "phased" approach:

Regarding the use of XML, the language appears to be a strong contender for the dominant markup language of the future. Office 2000 supports "saving as" XML. However, Microsoft has been known to change "standards" without gaining widespread support. The jury's still out on XML as far as we're concerned.

The use of XML in the submission header would appear to have little benefit since this information is only used by the SEC system. It would seem that markup language wouldn't be needed at all since custom tags could be created at will and be as complicated or as simple as the system required.

We do not have an opinion as to whether a disclaimer is necessary. If such language is deemed necessary, for ease of use, we suggest the language be allowed to be included on a (for lack of a better term) "disclaimer page". A reusable, one-page PDF containing the prescribed disclaimer language could easily be inserted into the unofficial PDF copy using Acrobat's "before first" option at the time of filing, eliminating the need to edit the original document.

The addition of multiple formats to the EDGAR system requires us to rethink the way these filings are stored and presented. End users would have the greatest ease if an index page for each filing was created (preferably "on-the-fly" to ensure the index is up-to-date) on the SEC's and value-added disseminators' web sites. The filing type, the date filed and (when applicable) the period the filing referenced would be included in the index's title. Ideally, this index would break down the submission by document and format and include any amendments to the filing in question. This would require the addition of an "<accession-number>" tag listing the original filing's accession number to amendment headers. Such a scheme would be facilitated by the storage of documents in a directory based on the original accession number for a filing. Sub-directories for amendments would exist beneath the original directory. Each filing directory or amendment subdirectory would contain the individual documents and unofficial PDF copies that make up the filing. The existing databases on the SEC's site and the disseminators' sites would have to be modified to reflect the new structure.

Using notations inserted into the exhibit index would not allow for notation of the inclusion of an unofficial PDF copy of the main document. A separate index noting which documents in the filing are accompanied by a PDF is superfluous because, if the end user has access to the PDF, they should already be aware of the existence of the PDF copy. If they don't have access to the PDF, the knowledge of its existence will do them little good.

We partially disagree with the mechanism for submitting an unofficial PDF copy after a filing has been accepted. The potential for abuse in allowing the replacement of existing PDF's without filing an amendment is recognized. However, we do not see a reason for requiring an amendment to be filed for the first-time submission of a PDF. If a filing is submitted without optional unofficial PDF copies, a mechanism should exist to file the PDFs at a later date by referencing the accession number and the document in the filing to which the PDF refers. This would reduce end-user confusion, eliminating the need to sort through several amendments to determine which contained substantive changes vs. those filed simply to include PDFs.

Animated graphics should not be used to represent critical data or purposes such as demonstrating performance due to the concerns broached in the Request for Comments. If these graphics were limited to purposes such as logos or emphasis only, the capture and representation of such graphics is not an issue.

We would prefer to see a quota for total graphics per filing rather than limiting the size of individual graphics. This limitation could perhaps even be expressed relative to the size of the HTML file, e.g., if a 3:1 ratio were used, a 200K HTML file could use 600K of graphics. Of course a minimum amount per filing would have to be allowed. Such a limitation will probably be necessary since one way to easily (bandwidth restrictions aside) present perfectly formatted financials is to simply make a graphic of the entire page. The same approach could be used for PDF file size limitations. Regarding the type of graphics accepted, any format viewable without "plug-ins" on generally available browsers would be a reasonable request. We see no advantage to limiting the total number of files that include graphic and/or image material if file size constraints are used.

If graphics are allowed, we see no reason why the graphical requirements for a printed piece should not apply to the HTML version. Conversion of the currently required graphics to "web-ready" format is a simple process.

Allowing links to other documents in the same filing and previously filed documents included by reference should be allowed. If absolute (opposed to relative) links were used or if disseminators did not follow the same directory structure as the SEC, filings would have to be modified to ensure proper linking.

Links to external sites would allow the potential for abuse. Such external links should not be allowed. The URL associated with a link is not obvious to the end user. A user could be directed to a different site than the text of the link represents. Such external links would require verification. The inclusion of textual references would still allow reference to external sites but would require entry in the "address bar" of the browser pointing out the fact that the user was about to leave an "official" site.

In any case, only those documents accompanying the filing and those included by reference (to the extent that they are now considered part of a filing) should comprise the official filing.

Use of such certificates would certainly be more secure than the current CIK/CCC password system. However, many filers use third party filing agents. How would this issue be addressed if such certificates were required?

We do not think this will be an issue. If a filer is advanced and concerned about appearance enough to use HTML format for their filings, they will almost certainly include a PDF of that document. We envision end users using the HTML version for on-line browsing and the PDF for printing.

Considering the other limitations put into place during the HTML implementation period, the proposed tag set will be sufficient.

How does the SEC propose to treat "white text" (text the same color as the background) and comments (using the "<!-- ->" tag) that would not normally be seen in a document viewed on-line or printed out but remain visible in the source file? If you view the source of this file, you will see examples of both at the end of this paragraph.