A publishing system without the capability to save versions (in the sense of revisions --not versions as in language versions) of stories, images, illustrations, and other objects, wouldn't be worth much. But what exactly is versioning and what can (and perhaps should) it look like? All publishing systems and editorial workflow applications support versioning one way or another, but the support may range from the ultra-simple to the very complex.One of the first questions that you must ask yourself when considering a system’s versioning approach is whether the system when saving versions, is saving complete versions or just the changes (delta). Obviously, delta changes are more lightweight, but need to be a second-level approach. Delta changes should be consolidated on a regular basis, either automatically, pre-defined, or manually.
A crucial component of a publishing system is the ability to promote previous revisions to the current one. This ensures that later versions containing messed up objects can be demoted to an earlier state, and the workflow can pick up from the last good state. The ability to do so, reduces the cost of getting it right, because it may be much faster to just start over from a last known point where everything was fine, than to keep setting things straight.
The rest of this article is Premium Content. However, we have decided to use this story as a showcase for what you may expect from a subscription to IT Enquirer. You will therefore be free to read on further.
vjoon K4 6’s “Rewind” capability is not a revision or versioning engine. The Rewind feature allows editors to revert back to a state where a document was known to be in good condition, i.e. no errors or faults were introduced at that state. When a document becomes messed up by subsequent edits, the Rewind feature allows the editor to go back to that last known “good” state. It is obvious that versioning is slightly different, because versions may not all be in a “good” state.
A system that stores and keeps all versions of a document is useless as it will rapidly run out of space or force the organisation using it to buy new storage capacity. The system therefore should allow for the removal of revisions. The only problem is to determine which versions to remove. One way to determine which versions may be removed is to define which type of version will be considered a minor one and which type a major one.
In WoodWing’s Enterprise 6 this is done by simply defining all document states that trigger a status change as major versions. These will be kept in the system indefinitely, while all other versions will be removed. This method makes a lot of sense because a status change normally will only occur at milestone moments. Nevertheless, even this method could result in too many or too few versions kept in the database. The only alternative would be to promote or demote document versions manually.
Another question you might ask yourself is whether the system can compare consecutive revisions and prior revisions. Such functionality makes manual versioning much easier. Look for systems that enable you to do this the way change tracking in Microsoft Word works. Easypress’ Atomik Dynamic Publisher allows for such easy versioning comparison by quickly generating a PDF rendition of the versions to be compared and placing them face to face on the screen, highlighting the differences in the process.
The system’s revision manager should all the while support the security features that are needed to enforce business rules related to documents and document distribution. This is less important in magazine, book and newspaper publishing environments, but extremely important in areas where document security is vital for the organisation, e.g. medical or pharmaceutical publishing environments.
Versioning: what to look for in a publishing system
A publishing system without the capability to save versions (in the sense of revisions --not versions as in language versions) of stories, images, illustrations, and other objects, wouldn't be worth much. But what exactly is versioning and what can (and perhaps should) it look like? All publishing systems and editorial workflow applications support versioning one way or another, but the support may range from the ultra-simple to the very complex.One of the first questions that you must ask yourself when considering a system’s versioning approach is whether the system when saving versions, is saving complete versions or just the changes (delta). Obviously, delta changes are more lightweight, but need to be a second-level approach. Delta changes should be consolidated on a regular basis, either automatically, pre-defined, or manually.
A crucial component of a publishing system is the ability to promote previous revisions to the current one. This ensures that later versions containing messed up objects can be demoted to an earlier state, and the workflow can pick up from the last good state. The ability to do so, reduces the cost of getting it right, because it may be much faster to just start over from a last known point where everything was fine, than to keep setting things straight.
The rest of this article is Premium Content. However, we have decided to use this story as a showcase for what you may expect from a subscription to IT Enquirer. You will therefore be free to read on further.
vjoon K4 6’s “Rewind” capability is not a revision or versioning engine. The Rewind feature allows editors to revert back to a state where a document was known to be in good condition, i.e. no errors or faults were introduced at that state. When a document becomes messed up by subsequent edits, the Rewind feature allows the editor to go back to that last known “good” state. It is obvious that versioning is slightly different, because versions may not all be in a “good” state.
A system that stores and keeps all versions of a document is useless as it will rapidly run out of space or force the organisation using it to buy new storage capacity. The system therefore should allow for the removal of revisions. The only problem is to determine which versions to remove. One way to determine which versions may be removed is to define which type of version will be considered a minor one and which type a major one.
In WoodWing’s Enterprise 6 this is done by simply defining all document states that trigger a status change as major versions. These will be kept in the system indefinitely, while all other versions will be removed. This method makes a lot of sense because a status change normally will only occur at milestone moments. Nevertheless, even this method could result in too many or too few versions kept in the database. The only alternative would be to promote or demote document versions manually.
Another question you might ask yourself is whether the system can compare consecutive revisions and prior revisions. Such functionality makes manual versioning much easier. Look for systems that enable you to do this the way change tracking in Microsoft Word works. Easypress’ Atomik Dynamic Publisher allows for such easy versioning comparison by quickly generating a PDF rendition of the versions to be compared and placing them face to face on the screen, highlighting the differences in the process.
The system’s revision manager should all the while support the security features that are needed to enforce business rules related to documents and document distribution. This is less important in magazine, book and newspaper publishing environments, but extremely important in areas where document security is vital for the organisation, e.g. medical or pharmaceutical publishing environments.