CM/ECF Data Enabled Bankruptcy Forms

Revised Data Enabled Form Standard Proposal

The "Data Enabled Bankruptcy Forms" project is nearly 18 months old and, sadly, has not been adopted by the bankruptcy software vendors. There are probably as many reasons as there are bankruptcy form vendors, but there are two reasons that seem to be common:

The proposed AcroForm standard for data enabled forms is technically challenging and the standard itself is incomplete (e.g. dealing with repeated or continued fields). Furthermore, the AcroForm standard does not fit comfortably with the workflow process of most of the vendors' products.
Data enabled bankruptcy forms are not currently mandatory. Given the modest market for bankruptcy forms, many vendors feel that it does not make sense to undertake an expensive and challenging technical project that is not required.

As to the later point: it is very likely that data enabled bankruptcy forms will become mandatory. Appropriate committees of the Judicial Conference will be considering a bankruptcy CM/ECF technical standard that would mandate the use of data enabled bankruptcy forms in electronically filed bankruptcy cases. If the technical standard is passed, it will likely take effect circa mid 2007. Thus every form vendor will have to address the issues of data enabled forms. Your written comments on the policy change to make data enabled forms mandatory will be included in the information submitted to the Judicial Conference committees. Written e-mail comments should be submitted by October 10, 2006 to: : John_Brinkema@ao.uscourts.gov and Monique.Bourque@usdoj.gov with a copy to Richard_Goodier@ao.uscourts.gov.

Regarding the complexity of implementing data enabled forms. As we have said many times, we are open to suggestions, and Marty Mohr, of EZ-Filing, took us up on the offer. We are seriously considering Marty's proposal (described below).

Marty has proposed an alternative way of associating data with a PDF form. The AcroForm approach would be (almost) totally dropped. In place of it, XML markup of the data would be embedding the PDF document. The vendor's form software process would be identical to what is done now (i.e. fields expanded or repeated as needed, generating an ordinary PDF document). After the PDF document of the form is created, a final process would create an XML document and then that XML would be inserted in the PDF document.

Marty proposed that the XML be inserted into the PDF document as the data associated with a single data field; that is, the PDF document would be an AcroForm with a single data entry field with the value of the field being the XML. I have reservations about this approach and have proposed a slightly different way to insert XML in the PDF document: as metadata. My proposal builds on Marty's but the data is inserted in the PDF document as XMP metadata. XMP is a widely accepted Adobe standard for metadata. XMP is a stylized XML built around the W3C RDF standard. With RDF, it is easy to add separate metadata clusters without worrying about what tags are already there and accidentally bumping into one another. Each alternative has its pros and cons.

In either case, XML in the PDF document appears to solve many of the problems associated with the current AcroForm proposal. The XML 'schema' would be based on the form-field tag set that we have already produced as well as the 'schema' that Marty provided in his proposal. There are some technical issues such as ordering of XML tags that will need to be addressed, but most of the work appears to have been done.

Because of the short time-line for implementation of data enabled forms, we will all need to work together to perfect our solution and the standards that our solution will be based on.

Please read our disclaimer.

Suggestions for additional content or comments on this site may be made to developers@psc.uscourts.gov. E-Mail