Extended Rights: A Manifesto
This document is intended to sketch a framework of principles for the “ideal” model for Extended Rights in PDF.
When we say “ideal”, we are speaking from a third-party perspective, one that respects Adobe’s right and interest in monetizing Extended Rights in PDF forms, but that also accepts the customer’s interest in a technology that is flexible, highly functional, exceptionally simple and entirely cost-effective.
Unlike content creation (Adobe’s main focus outside of PDF), forms are a “line of business” technology in most organizations, vital to daily operations. This may explain why Adobe has struggled to fully convey the power of Extended Rights to its potential customers. Those of us in the professional PDF community don’t wish it to struggle a moment longer than necessary.
NOTE: Suggestions for amendments or additions to the Manifesto are encouraged! Please email me, or comment on the Blog. If we use your comments on the Manifesto, your name (if you wish) will be added as a Contributor (see the bottom of the Manifesto).
Background
For these purposes, “Extended Rights” amount to a “switch” within a PDF. When the switch is “flipped”, users with the free Adobe Reader may not only fill out a PDF form, they may SAVE a filled-out copy on their local computer. As of this writing, Adobe Acrobat Professional 7.0 includes the capability to add Extended Rights to PDFs for the purposes of Commenting only. Extended Rights for the purposes of saving forms are currently only available via the Adobe LiveCycle Reader Extensions Server (ARES), and through FormRouter, an Adobe licensee.
Extended Rights: A Manifesto
Article 1
Acrobat Pro should be able to “bless” PDF files with Extended Rights (ER).
Discussion following the release of Acrobat 8.0
Article 2
Acrobat Pro and Adobe Reader Extensions Server (ARES) should always complement each other, and never compete.
Discussion following the release of Acrobat 8.0
Article 3
The pathway from Acrobat-driven ER to LiveCycle-driven ER should be SMOOTH.
Article 4
Scaling from Acrobat Pro-driven ER to LC-driven ER should NEVER imply operational risk to the application. Users should never have to endure a “hard stop” to their workflow simply because (for example) orders peaked in the third quarter! “Crash” installations of ARES to overcome a limitation in Acrobat Pro won’t be good for anyone.
Article 5
The limits on Acrobat Pro’s ability to add Extended Rights should themselves be EASILY extensible via a simple pay-as-you-need-it scheme. For example, if Acrobat Pro were to have the ability to make 250 instances of a form “reader-savable”, then each licenced user should be able to purchase (without ARES) the ability to make the same form savable for 500, 1,000, 10,000 or 25,000 instances at additional cost, using a simple online payment method.
Article 6
Extended Rights can be monetized at desktop and server levels alike, and the benefits of each should complement the respective solutions. Right is “right-sizing” the application.
Article 7
The correct role for ARES is as a way to CONTROL costs for PDF forms, not to IMPOSE radical new ones, as is currently the case. ARES could allow Adobe to charge for actual usage rather than estimated usage, and allows users to coherently manage Acrobat-enabled forms. Together, these advantages will offer clear savings to larger customers compared with the “pay as you go” method. In other words, the argument for ARES should be turned around - it should be sold primarily as a management and cost-containment tool, not an enablement tool as such.
Article 8
NEVER tell the users how to manage their forms! Let them save, edit, submit, collate, print, scan, OCR, FDF - WHATEVER. Do NOT assume that “most significant use-cases” are reducible to (for example) the ability to convert form instances into a spreadsheet.
Article 9
XFA or acroforms: the distinction should be transparent with respect to Extended Rights. Do NOT fail to support acroforms!
Article 10
Separate “form” rights from “save” rights. PDF forms are often used for document applications rather than as forms per se, as in CD-ROM interfaces, electronic brochures, and so on. These applications may require Extended Rights to import FDFs (for example), but do not require the ability to save a form. For these purposes, Acrobat Professional should be able to bestow form rights on a PDF without limitation or reservation. With these “pdf as application” rights applied, the default form-related warnings to the user when opening or closing the PDF would not occur.
In this way, it would become very easy to develop “application” PDFs using the full suite of forms functionality without interfering with a “real” forms oriented business-model for Extended Rights.
