Technical standards

 Technical requirements primarily affect information delivery. There are, for example, U.S. government agencies that require information to be delivered in a specific format, such as SPL (XML standard for drug information) or MIL-STD-40051 (a U.S. Department of Defense standard for technical manual preparation).

Noncompliance is probably not an option, so you have just a few choices:

  • Set up an authoring and publishing environment that creates the information products as specified.
  • Create information products in a noncompliant format and then convert them to the required format.
  • Hire a third-party vendor to create compliant documents from whatever you are creating.

Options for technical compliance

Many government regulations now specify XML as a required format. In the past, regulations were more likely to require a specific delivery mechanism, such as paper or PDF. It was left to the organization creating the information to determine how to create the final format. But today, the requirement for XML goes much deeper. Instead of focusing on document appearance (double-spaced, uses a specific font, and is printed on US Letter paper), requiring XML means that you must correctly encode the meaning of the information. For example, a part number might need to be presented in boldface (22-44-66). In the XML specification, there are at least two ways to tag a part number that result in boldface output:

<b>22-44-66</b> <partno>22-44-66</partno>


Only the semantically correct approach (<partno>) would be acceptable.

Another example is Extensible Business Reporting Language (XBRL). The U.S. Securities and Exchange Commission requires reports in this XML standard, which is used for financial and other business information. Here are a few lines, chosen at random from a Google filing (and somewhat simplified):

... <FurnitureAndFixturesGross>65000000 </FurnitureAndFixturesGross> <Goodwill>4903000000</Goodwill> <IncomeTaxesReceivable>23000000</IncomeTaxesReceivable> <IntangibleAssetsNetExcludingGoodwill>775000000 </IntangibleAssetsNetExcludingGoodwill> ...

Authoring in a standard office word processor with styles called Normal, Heading1, and so on will not result in information with this level of specific encoding.

Building a compliant publishing system

Setting up a publishing system that supports complex technical requirements is not for the faint of heart. This approach makes sense, however, in the following scenarios:

  • A significant percentage of your business depends on compliant content. (For example, you are a defense contractor and are required to follow military standards.)
  • You cannot afford any delays in content delivery. (For example, you are a pharmaceutical company, and you do not want a drug launch to be delayed because you are still converting over to the required format.)
  • It is less expensive to set up a system in-house than it is to hire a vendor to do the work.
  • Conversion is time-consuming and error-prone because the source files do not contain all of the information needed to generate the conforming files.

For authors, working in a specialized system will require training and support to help them understand the new workflow. Full-time authors are generally expected to master professional tools, but if your content is created by part-time authors who have other responsibilities, the use of specialized tools can be a challenge.

Converting to the required format

Instead of upending your established content creation process, you can add conversion as a caboose to the established publishing process. The main advantage to this approach is that content creators do not have to change how they work.

In some organizations, the content creators are subject matter experts (SMEs) with many other responsibilities. For example, a research scientist or a software engineer may be expected to contribute some content. For highly paid contributors with unique expertise, it can be sensible to accept content in a non-compliant format and leave the publishing tasks to support staff.

Most often, the non-compliant format is Microsoft Word. That is, content is created in Word files and must later be converted to another format. Some automation is possible, but you can expect that conversion will take a significant amount of time (several days or several weeks) after the document content is completed. In-house conversion makes sense in the following situations:

  • The requirement for compliance is a one-time event. For example, your organization has a single government contract that requires delivery in a specific format.
  • Content creators are unwilling or unable to change their workflow.
  • Content creators’ time is so valuable that a change in workflow is out of the question.
  • In-house staff has the expertise to either build a conversion process or to do a brute-force conversion.

Other than the time required to convert the content, the biggest problem with a back-end conversion is that the source content may not include the needed information. Final documents may require metadata (such as the author, last modified date, and document type) that is not available in the source format. The only way to ensure that the information is available is to build a process that takes those requirements into account.

Offloading compliance onto a vendor

Some organizations go a step further by outsourcing conversion to the required format to an outside vendor. This is reasonable for a one-time custom requirement, but if you are creating a lot of regulated content over time, you probably want to keep the process in-house. Most vendors use a combination of scripting and brute-force retagging to get the content into the required format. Outside conversion is often expensive and time-consuming.

For government contracts, you may be limited to in-country vendors.


Add comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.