In the third of a series of posts looking at developing a revision workflow, we look at the editorial workflow and considerations around types of changes, approval, and the first steps in transforming from one stage to the next.
Now we have the data structure framework to underpin our processes, we need to establish some corresponding processes for getting from some existing entry (if there is one) and the note of some possible change to a finished entry ready for integration back into the dictionary data.
As with the development of the structure, so too for the processes we start by looking at the editorial demands. We note first that the processes here are going to be applied chiefly to individual one-off changes, i.e. those concerned with single entries or parts of entries (though the new revision structures, being XML, and transformations, as XSL, should therefore be equally suitable for handling global changes in due course): each change will be different in what is being done, where, and to what.
Reviewing the noted problem or existing proposed change, doing appropriate research, and deciding what change to draft into the new structure will be the core of the editorial task, and the protocols and procedures for these will doubtless evolve with time as our experience of this way of working grows. Key to them, however, will be an underlying assumption of validity and stability: the existing text was the result of painstaking research and checking and so it merits prima facie respect as being reliable. While any publication that has been the work of so many people over many decades inevitably exhibits a degree of variability through its pages, pretty much regardless of the strictness of its protocols, the fact that a portion of text is not precisely as consistent as it might be with other parts or is not as we would do ourselves now is not per se a reason to decide to amend it: not only are there multiple ways of treating any particular matter that are good (albeit in different ways), but also there maybe complex (even unseen) dependencies resulting from the printed text in earlier parts being what editors made reference to when preparing later parts.
Our aim for now is not the preparation of a fresh edition, which would be a wholly different undertaking. Instead the process is intended to correct or remove error and to supplement where there is significant omission (e.g. of an entry or sense). A principle of minimal interference will help us avoid (a) during our limited time being distracted from the important corrigenda/addenda by rearranging things that do not strictly need it and (b) inadvertently causing knock-on problems.
Looking at each problem or proposal in view of what is currently printed, we can decide whether to make a change, what the (smallest) change would be (e.g. of a quotation, subsense, sense, cross-reference, or whole entry), and whether it is of the kind that it should appear in a printed list of corrigenda: the most minor changes, e.g. inserting a missing bracket, can simply be made ‘silently’, to be visible in the data when published online.
Once decided, the change can be keyed directly into a copy of the entry. The former unchanged version, if there is one, will be the <for> child of the <revision> element, and the newly amended version, if there is one, will be the <read>. For some changes that we want to print notices of, e.g. ones that fall within longer elements such as a change of a word within a quotation, we will expect a <print> element to give the relevant printable details in a correctly tagged form. A <note> explaining or justifying the amendment may also be provided.
All these amended copy entries are gathered to be reviewed by the editor. At this point we have several transformations to assist in and carry out the processing. First, all the changes can be reviewed in draft by an XSL transformation run across all the amended files as an XML collection (using the invaluable collection() function) that pulls out the relevant <for> and <read> instructions. Any that are obviously problematic can be identified and returned for further drafting.
After this each entry containing a draft amendment can be looked at individually and the change considered in context. If approved, its form is finalized, including marking of the approval and a decision on whether the change is to be printed.
Finally, the approved draft changes are implemented in the entries and the entries sorted for reintegration back into the overall dictionary data, from which a formatted list can subsequently be exported for publication.