Tuesday, April 02, 2019

More Missing Bits

Following on from the previous Blog about missing bits I have recently discovered another Element that is not always where it was in the past. In fact it has been removed from the Procedural Module. The, some love it, Element - Caption Group.

I was doing some in depth testing recently and tried to check out its operation in a procedural data module. I had just tested a descriptive data module with the caption group. But although caption text was available there was no caption group. Is this an accidental omission or is it omitted as the result of a request I wonder?

Caption Group

This element is no longer in the procedural data module schema. When this structure was first conceived it was to assist in the production of Crew documents to show indicator mimic panels are various states in the various procedures. When this first sstructure saw the light of day it was denigrated - why on earth would anyone want this structure. Over time an increasing number of people found that it made certain indicator and control displays very easy to mimic without the need for an illustrator to create this as a graphic. Those people found the added advantage that the author could update it very easily.

The structure rapidly migrated to several of the other data module types.

The structure of this element was chosen so that it was possible to 'modify' the way an editor (or output device) used the standard CALS table model. Again in the beginning structure was limited to the Crew Data Module it was fairly quickly migrated to a number of other Data Module Types. There were, I understand, heated discussions on the use of this Table Model. Perhaps the discussion reflected the composition of the committee that 'ran' S1000D and its development. Although I was the one who came up with the original Crew structure in General and the Caption Group in particular I only heard about its adoption and migration.

Should it return

Perhaps the discussion should now be "Should it be returned to its previous location".
Although I now spend most of my time in a support role with Authors at the coal face I rarely get to see any significant body of documentation, particularly in the current environment where so much material created in the US has had the ITAR stamp put on it.


This is a very interesting subject.

Many years ago I was tasked with the job of converting a standard, desk top, manual switch unit used by thousands of offices throughout the UK (and further afield) to redirect telephone calls to desk telephones. The original handbook was a soft cover 20 page or so publication. Uncomplicated, using off the shelf components in a fairly simple case.

The book was reformatted into a ministry type publication and immediately had a Restricted Security rating placed on it. Despite several attempts to remove this classification, it retained the classification to the end.

It strikes me that the ITAR concept is more or less in this mindset. I have heard of several sets of Data Modules which have been written on this side of the Atlantic for fairly uncontroversial items of equipment which have been included in US DoD (and civilian) publications and have ITAR placed on them. Even the people who wrote them in the first place are not now allowed to view them. Indeed we have created a 'Scrambler' so that we are able to fault diagnose problems which have occurred.

So. A simple question......
Does this make sense
Is it overkill?

Tuesday, March 05, 2019

Missing Bits

Over the years the S1000D Specification has gained quite a few additional features which have in the main been useful. Granted some of the features have been questionable and some in the community have wondered where the ideas have come from or even why they have been added.

Level Attribute

Some of you may remember that I have mentioned that the very useful attributes Level was removed when Issue 4 of the Spec was released. The fact that this attribute was removed tended to indicate that those on the steering committee had never worked in a small company where very few had a CSDB to manage their Data Modules.

To recap: The Level attribute was provided to indicate the Issue Number that a Data Module was changed. This was extremely important as the original intention was that the Data Module should contain a complete record of changes. This deemed necessary in the event of any investigations which may have been needed if there had been an incident. By metaphorically picking up a Data Module and looking at it an investigator would be able to see what changes had been made and when.

With the steering committee comprising more management types the link between the 'small' maintainer and the big companies was lost. In addition, the skills of those who were involved in implementing the specification were not up to the more professional programmer.

I do know that from an early time an influential member of the steering team decided to strip out all historical information. I know that there were repeated attempts to get the Level attribute returned to the specification, to no avail.

The level attribute was very useful in the publication of books using systems which kept track of changes to the data modules. Pity that that facility has now gone.