S1000D & SGML - Who should know what?

This post is relevant to S1000D, so bear with me… I have recently been involved in helping a company that is receiving SGML files (not S1000D) from a sub-contractor. Having looked at some of these files it is obvious that the material being supplied is far from perfect, and I really mean far.

The problem that I have been encountering is that the staff at the receiving company does not have much real understanding of SGML. So even after I pointed them in the direction of a really good free SGML Parser with a Windows front end - they did not know what to do with it, the significance of the reports it was going to give them or even how to find out what exactly is wrong with the files.

So what has this got to do with S1000D?
It is becoming increasingly obvious that this lack of understanding is a problem which is also affecting the work in the S1000D arena. As more companies get involved in the production of Data Modules the lack of knowledge is going to cause increasing difficulties. We have already seen this happening in the UK and with the US gradually moving to S1000D the problem is only going to get worse.

If everyone is working with configured SGML Editors that is fine, but as we know some editors are better than others.

It is where someone is not using a properly configured editor, or they have undertaken some conversion work (perhaps using search and replace in a text editor), or where a text editor has been used for some of the work that problems are likely to occur.

Working S1000D is going to result in huge numbers of Data Modules being sent between companies. Because of this:

- Part of any dispatching process has to be the checking of the delivery for conformance.
- Part of any receiving process has to be checking the delivery for conformance.
- There must be at least one person in a company who understands something about SGML.

Obvious? Perhaps not.

From the comments I am receiving this clearly is not the case in the S1000D and other environments. Indeed, when I mention this requirement to the person making the comment to me for the most part they seem to think that I am speaking a foreign language.

The contract placed on a company working with S1000D is to provide S1000D Compliant Data Modules. Unless the company sending them has independently checked, then how can the QA system indicate that they have complied with the contract. Unless the receiving company has independently checked the Data Modules, how can they show in the QA system that the supplying company has complied with the contract placed on them? Also, if the incoming S1000D Data Modules are not 'behaving' correctly in their SGML editing environment how will they be able to say whose fault it is (i.e. the Data Modules, the Editing Software, or the delivery system)?

To make this work it is obvious that there must be at least one person within a company who is partially knowledgeable about SGML/XML. I think that these people must have the following minimum skills:

- Understand, at least in outline, what SGML/XML is about
- Understand the tools that are required for Editing
- Understand the tools required for checking the Data Modules
- Have sufficient knowledge to interpret the output from the checking software so that the 'faults' can be apportioned to the right area.

And then of course - Business Rules

This brings us back to S1000D and Business Rules. Not that S1000D is the only place where business rules have a place; ATA iSpec 2200 projects also need them.

Without Business Rules it is not possible to have consistent Data Modules (except by accident that is).

The Business Rules will clearly contain the process that should occur:

- prior to delivery,
- during delivery, and
- when receiving packages .

Clearly the appropriate processes above will include steps to independently check the S1000D Data Modules for, at the very minimum, compliance with the correct DTD.