Forms Development

[Ann]

We use Arbortext Editor 5.3 with Styler and normally we develop procedures and training manuals and it works very well for that. Management has asked if we could create forms in Arbortext Editor in XML. The only thing I can come up with is using the table feature but it doesn't seem like the best choice or very user friendly for future edits. Before I go back to management and explain that, I wanted to get other opinions. Any ideas?

[DmitryTsarev]

Ann

What final result do you need to achieve? Why do you want users to enter data in forms?

Why not just make users enter data to several tags/elements and attributes in Editor (without any forms) and then put it where you need in the output publication using stylesheets?

[JamesMason]

I agree that the first requirement is to establish goals for a forms system. Do you want to edit a form as a form, or do you want to collect data that will be displayed as a form when it is composed/printed?

In Microsoft Word it is relatively easy to use tables to create fillable forms that look like forms. But Arbortext is an entirely different animal.

While it is possible to use information-specific elements in an Arbortext "custom table"to build something form-like, the custom table mechanism has severe formatting limitations. Conventional HTML tables are less restrictive than custom tables when it comes to presentation, but you lose the ability to have application-specific elements.

We have built a system that combines application-specific XML for creating forms as part of a whole document life cycle, but the documents look only partially like forms in Arbortext (e.g, metadata just looks like unformatted elements, but a tabular procedure is a custom table). We use XSLT to create HTML that is displayed on a Web server for the end users to fill in; that looks like real forms. The data supplied by the users is collected in another XML application, and we merge this data with the XML of the form template, once again using XSLT. The resulting XML file is then rendered to PDF, using Publishing Engine. The result looks good, but it's not the same as editing forms as forms in Arbortext Editor itself. If you want to see what the system looked like a couple of years ago, look at the paper we presented at the XML conference "Balisage 2008": http://http://www.balisage.net/Proceedings/vol1/html/Mason01/BalisageVol1-Mason01.html

Some of the details, such as the schema for the XML in which we record user input, have changed since 2008, but the system architecture remains as described then in the production system we are using now.

We're doing some other forms in XML in which we eumulate Word tables, using HTML tables. But we don't edit these forms in Arbortext, just compose them to PDF there. The forms are generated by XSLT, harvesting the data from other documents that are edited in Arbortext, including markup that identifies data that will go into the forms.

I'd be glad to discuss our work.

Jim Mason

Y-12 National Security Complex

Oak Ridge, TN

865 574 6973