Where or What Next for S1000D?

S1000D Issue 2 Change 2 is issued and I think we all know that the various committees are now working towards S1000D Issue 2 Change 3. And a thought occurred to me (yes - my grey cells do work occasionally) - what would the greater S1000D community, i.e. the people who are working with the S1000D Specification, like to see in the way of enhancements, modifications removals or a wish list.

I know that we all have a common language and some of my S1000D support work reminds me just how common some words are (a joke of course). So I thought that I would define what I mean by each. A couple of the definitions may seem close to each other but I put them in never the less, if only to perhaps provoke some discussion. I have put examples in some of the definitions but of course they may be my ideas alone or something that I have heard others discussing.

Modifications to S1000D

This category can be defined as a change that will make the functionality of S1000D more useful as a vehicle for data. Let us not forget that the sole purpose of S1000D is to provide a maintainer/trainer with the information that is required to enable him/her to carry out their work efficiently and accurately.

From time to time there is obviously a need to modify the S1000D so that it can, for example, keep in touch with technology. The move towards XML is a prime example of this. But my plea is that the modifications to S1000D should be for the common good and not just because one specific branch would really like the change.

Enhancements to S1000D

This category can be defined as a change that will make working with S1000D easier or simpler. The sort of thing that might be included here is a change in the S1000D structure which will not affect the overall way in which the authors author the S1000D Data Modules.

An example of this, although I do realise that the structure has been changed now, was the specpara content. In a project that I was at the receiving end of it was obvious that the people authoring the DMs had not realised that they were creating normal content whilst in the specpara structure. It was possible to create content using the paragraph element on its own without a warning, caution or note.

I know that a comprehensive Business Rules Checker could and should be made to trap this but surely anything that would make this unlikely in the first place would have been preferable. I know that such a structure was devised and the end result was indistinguishable from that created by the original, so output devices such as IETP rendering would not have been affected.

Removals from S1000D

As in all specifications, S1000D must have some structures which are not used.

We have the ability to mix Issue/Change DMs in publications. (Honest, despite what some say and if your CSDB cannot handle this then get the provider to change it so that it can.) Because we have this ability to mix DMs there is no need to retain some of the structures that were there previously just because "They have always been there." I am sure that some of you can think of items that fall into this category.

Personally I think that this category has a fairly low priority compared with the others.

Wish List for S1000D

This category can be defined as something that, as a producer of material using the S1000D specification, you feel would make your work easier.

I suppose one possible inclusion in this list would be a better definition of what each of the elements should be used for. There is plenty of material about the content of the Data Module Code, after all there are tables giving the first three characters in the SNS code and the IC code. But what about a definitive statement on how the remainder of the (say) six SNS characters should be handled? Given that the first three characters are hierarchical should not the remainder follow that principle?

If something is proposed in the specification, should there not be a good example of how the S1000D committee intends it to be used.

OK, I realise that Business Rules will take care of these two, but what about the following:

1. Giving the wider S1000D community the opportunity to look at the proposals before they get incorporated into S1000D.
2. Do not tinker with S1000D for the sake of it.
3. If there is a change to S1000D perhaps provide the reason for it - I think that this item alone would remove a few of the grumbles that I hear about S1000D.

So what do you think about these categories?

S1000D 101: Before You Start - an Overview of the Initial Stages of Working with S1000D

The first in the series of S1000D 101 is now available. It is too large to be sensibly put onto this Blog so to get “Before you Start - an overview of the initial stages of working with S1000D” follow this link to the PDF file.

This paper puts forward a very neutral view of what is required to start working with S1000D. It is not exhaustive and takes a very independent line on S1000D software requirements and talks about functions in general.

My thoughts about comments still stand. If you would like to write something which puts another point of view please feel free. If you feel that you can contribute with a neutral paper on S1000D which is not overtly linked to a specific application please get in touch. If you have an "S1000D White Paper" on your company's site that extols the virtues of a particular S1000D application we will be interested and could possibly provide a link to it in some way.