Tuesday, September 17, 2019

Small Apps for S1000D Users

Very very rarely do I ever push applications which Mekon has on its shelves but on this occasion I thought that I would flag up some useful stuff. Our clients are from a wide range of sizes from the large corporate to the much smaller one or two person band. All are equally important to us but our smaller clients often operate with a distinct disadvantage in that they cannot afford an S1000D compliant CSDB. Of course the functionality of the various CSDBs can be considerably different.

Without a CSDB there are a number of functions which have not been available to them. For a start I mention just two of them and provide just a little bit more information about them.
  • Assisted Data Despatch Note creation
  • Assisted Illustrated Parts Data creation

Assisted DDN Creation

The creation of a Data Desptach Note can be a fiddly occupation usuallly requiring the copying of filenames and then some serach and replace to get the various elements wrapped round the data. As part of the Product Improvement practice that we undertake from time to time we decided to incorporate this within our standard S1000D Editor application. Such a little thing but it makes a huge difference to the day to day running of S1000D projects.

Assisted Illustrated Parts Data Creation

I remember as if it was yesterday when the IPD data module DTD was released. At that time I was involved in a UK Navy project migrating existing parts lists into S1000D. Although we were heavily involved in S1000D Feasibility Studies for the UK MoD the powers that be would not release the DTD to us even though we were also heavily involved in S1000D specification work (even creating one of the Data Module types). I think we were horrified when we saw the DTD in a Visual DTD application. It was explained to us that it was to be a mechanism to send data from one S2000M user to another.

Is it any wonder then that the Business Rules associated with several projects that we have seen over the last three or four years have clearly stated the the Illustrated Parts Data Module should not be created by hand.

So what do you do? You create a  standalone application which enables you to create the IPD Data Module using an enhanced output from a parts data base The enhanced output is a spreadsheet file of the parts data. All databases can output spreadsheet files as a report on a table.

Mekon has provided a short series of videos which show how this application works.

Mekon also have a similar application for the ATA iSpec2200 Illustrated Parts List specification.

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?