This article discusses the issues that WSDB users experience in eMRD when entering Subtask Descriptions and subsequently printing PSS Reports. We are publishing this article to elicit some discussion from interested users to determine the viability of implementing a solution in eMRD.
EDITORS NOTE: If you don’t want to read through the Background and Current Dilemma but just read the Proposed Solution you can jump to it here.
Background
Subtask descriptions are stored as multiple lines of up to 65 characters in the WSDB, but are reformatted to narrower widths depending on the type of report in which the task appears:
| Format |
Maximum Characters |
Normal
format Signup |
22 |
Normal
format Non-Signup |
28 |
Extended
format Signup
|
36 |
Extended
format Non-Signup |
42 |
EE508
format |
22 |
It is the same problem one would get in Word if every line in a piece of text was terminated with a Return. It might look good on the screen after typing it in, but as soon as the margins are moved in causing the lines to wrap, the formatting goes out the window. In a word processor, the user only presses Enter when a new line or new paragraph is required, the rest of the text is left to wrap as necessary by the margin settings. In a word processor however, special characters are embedded in the text to ‘remember’ where Returns are so as to distinguish an intentional new line from a new line caused by word wrapping.
In eMRD, when the user enters the Subtask Description, word wrapping occurs according to the textbox width and new lines can be forced using the Enter key. However upon saving the task, the text is stored as it appears in the textbox, ie, n lines of text. According to the 038 no special formatting characters should be used, eg tabs and the DEFAUST defines the allowable characters for the narrative field. As a result, no special codes can be stored to differentiate between a word wrapped line and a forced new line.
When a Subtask’s Description is read from the WSDB into the Task Edit form, it is displayed exactly as it is stored in the WSDB, ie, as n lines of text. It looks fine because it is being displayed exactly as it was when it was saved. However, when the same narrative is read from the WSDB for the purposes of printing in a PSS report, is still read as n lines of text but has to be reformatted into one of the 4 new widths (as described above).
Dilemma
From the programmer’s perspective, there are two ways to treat the narrative to achieve the necessary reformatting:
- Join all the n lines of text (from the WSDB) together and allow the report to wrap as necessary; or
- Treat each of the n lines (from the WSDB) separately, allowing each to wrap as necessary, and starting each of the n lines on a new line.
Neither method works correctly all the time. The advantage of Method 1 is that it avoids the problem of printed lines with only a few characters followed by another line which could have wrapped. The disadvantage of Method 1 is that any intentional new lines are not printed as new lines. The advantage of Method 2 is that intentional new lines are printed on new lines. The disadvantage of Method 2 is that printed lines with only a few characters occur followed by another line which could have wrapped.
Current Solution
eMRD currently has a solution built in. This solution necessitates the user setting the width for the Subtask Description textbox (in the Task Edit form) to the appropriate width for the PSS Report format in which the task will be printed. The narrative will then appear in the report exactly as it does in the Task Edit form. This is all well and good until a decision is made to print the PSS using a different format. Then all the careful formatting at task entry counts for nothing.
For example: A WSDB’s task narratives may be printed for Normal Sign UP Work Cards (maximum 22 characters). AT times, when the work card is printed, users may notice some words wrap unnecessarily. To get around this issue, users can force the 22 character limit by using the utility in eMRD Task Edit screen. However, if, later on, users choose to use some other format (say Extended Signup – maximum 36 characters) those tasks that were forced to 22 characters will remain that way.
Let’s see this pictorially below:
We create a task narrative and allow our narrative to span the full allowable 65 characters per narrative line (actually record is the more correct term)…
… when we print a work card formatted for Normal – Sign Up (maximum 22 characters per line), we notice that the word “DETERIORATION” has wrapped to the next line. This has happened even though it is obvious it could fit on the line above.
Why does this happen? It happens because the word “DETERIORATION” is actually stored on a separate task narrative record for the sub-task. The report generator interprets this as the need for a new line as this cannot be distinguished from the user happening to select a new line by using the ENTER key.
One way of fixing this is using a utility available in eMRD and forcing the format in the task edit screen as shown above …
… and we end up with this. When this utility is used, eMRD will actually store the narrative in chunks of 22 characters or less.
In Normal – Sign Up format the work card now looks acceptable, …
… and returning to the Task Edit screen, the user sees this. Note the format drop down list does not show what workcard the narrative is formatted for …
… but the narrative is still stored in 22 character chunks (or less). What’s the problem with this? Well, what happens if you want to change the format of your work card …
… as you can see, the tasks we haven’t forced the formatting on (left hand work card) are fine in Extended format, but the one we did (right hand work card) retains its 22 character (Normal – Sign up) format.
So what’s needed?
What is required is a field in the Subtask Description table which can indicate which lines are due to word wrap and which are due to intentionally starting a new line when entering the narrative.
The WSDB table which contains the PSS Task Subtask Descriptions is table RO. Table RO is identical in structure to table CC, which was the Subtask Description table in MIL-STD 1388-2B. Table CC still exists in DEFAUST 5692, but is not used for storing PSS Subtask Descriptions. Table RO already has a field called the Element Indicator (DED 095), the purpose of which would seem to be redundant.
In DEFAUST 5692, DED 095 is defined as a single-position code to indicate whether or not the procedural step is a task element. Allowable values are ‘E’ and Blank. ‘E’ indicates that the text represents a Task Element, the smallest logically and reasonably definable unit of behaviour required to complete a task or subtask. Blank indicates that the text does not represent a Task Element.
Furthermore, in DEFAUST 5692 there are 2 rules for Table RO regarding the Element Indicator:
- The Element Indicator “E” is documented against the first line of a given element narrative, and is blank for all subsequent lines of that element narrative.
- Element narratives must begin on unique lines (Text Sequence Codes). For example, one element cannot end on line 12, and the next task element begin on line 12 also.
Proposed Solution
In effect the Element Indicator does not perform any real function in a DEFAUST 5692 compliant database. LES is proposing that the Element Indicator in Table RO could be used as the New Line indicator. eMRD will handle the assignment of the Element Indicator according to the input of the Subtask Description. It would assign an ‘E’ to the first line of the Subtask Description (as it currently does) and also to the first line after Enter is pressed. This will allow the PSS reports to determine what text to word wrap and when to start a new line. From the user’s perspective, there will be no change in using eMRD, the only indication will be that all PSS reports will format the Subtask Description as intended regardless of the format chosen.
We recognise there would be an overhead for existing databases if this proposal was implemented in that future PSS reports may not format correctly without revisiting each Subtask Description. However, as part of our solution, we will add an “Element” option in the ADO Report screen for printing PSS Work cards. If the “Element” option is selected, then the report generator will create a new line whenever it encounters an Element flag (aside from the very first line of a narrative block). If the “Element” option is not selected then eMRD will behave as it does now. This option will be saved against the EIAC so users do not have to reset it each time they use the ADO Reports screen.
LES does not see any unexpected behaviour from OmegaPS when it is used to generate PSS reports from an export file generated by eMRD, although admittedly we don’t know how it treats the Element Indicator..
