Topic-based authoring is a kind of modular authoring. Modular authoring is simply any kind of authoring where content is written in reusable pieces (modules), which may then be combined to form one or more publications, instead of writing a publication as a single unit. One advantage of this approach is that when two publications contain the same information, you only need to update that information in one place. DITA calls these pieces topics, and S1000D calls these pieces data modules.

S1000D is more of a whole process for creating technical documentation. The specification includes XML schemas which are used for the actual authoring of content, but it also covers much more, such as data exchange, quality assurance, version control, presentation in both page-based and electronic formats, etc.

That said, the S1000D schemas are more rigid than DITA. DITA allows a lot more customization of the schemas through specialization. S1000D really only allows you to add extra constraints on top of the schemas by use of Business Rules Exchange (BREX) data modules, and a tool which can validate S1000D modules against a BREX.

For example, the schemas allow the values of attribute emphasisType to be "em01" thru "em99", but you can limit your project to only using "em01" (bold) and "em02" (italics) with a BREX rule:

<structureObjectRule>
<objectPath allowedObjectFlag="2">//@emphasisType</objectPath>
<objectUse>The value of attribute emphasisType must be em01 (bold) or em02 (italics)</objectUse>
<objectValue valueForm="single" valueAllowed="em01">bold</objectValue>
<objectValue valueForm="single" valueAllowed="em02">italics</objectValue>
</structureObjectRule>

The BREX validation tool would present the erroneous XML branch to the user with the objectUse message if they used "em03" for example.

S1000D also has a very particular paradigm for the creation of modules, using a Standard Numbering System (SNS) and information codes. The SNS tells you what component of the product that module is about, and the information code tells you what kind of information the module contains about the component.

For example, if you define the SNS 32-00-00 to mean "Landing gear", and you take the information code 040 which means "Description", you get the data module "DMC-PLANE-32-00-00-00A-040A-D" which is titled "Landing gear - Description".

To hopefully clear up your confusion about publication modules, they define the structure of a publication only. They list what data modules will appear in the publication, and in what order:

<pm>
<identAndStatusSection>
<!-- snip -->
</identAndStatusSection>
<content>
<pmEntry>
<dmRef>
<dmRefIdent>
<dmCode modelIdentCode="PLANE" systemDiffCode="A" systemCode="00" subSystemCode="0" subSubSystemCode="0" assyCode="00" disassyCode="00" disassyCodeVariant="A" infoCode="001" infoCodeVariant="A" itemLocationCode="D"/>
</dmRefIdent>
<dmRefAddressItems>
<dmTitle>
<techName>Aeroplane</techName>
<infoName>Title page</infoName>
</dmTitle>
</dmRefAddressItems>
</dmRef>
<!-- more data module references... -->
<dmRef>
<dmRefIdent>
<dmCode modelIdentCode="PLANE" systemDiffCode="A" systemCode="32" subSystemCode="0" subSubSystemCode="0" assyCode="00" disassyCode="00" disassyCodeVariant="A" infoCode="040" infoCodeVariant="A" itemLocationCode="D"/>
</dmRefIdent>
<dmRefAddressItems>
<dmTitle>
<techName>Landing gear</techName>
<infoName>Description</infoName>
</dmTitle>
</dmRefAddressItems>
</dmRef>
</pmEntry>
</content>
</pm>

You can also create hierarchical groups by nesting <pmEntry> elements and titling them with <pmEntryTitle>

Lastly, I'd like to slightly correct one thing you quoted:

This points to one of the key differences between DITA and S1000D, which is the granularity of the level of reuse. While S1000D encourages reuse at the data module level (roughly equivalent to a topic within DITA), it does not have mechanisms for intra-data module reuse.

S1000D does have intra-data module reuse, via Common Information Repositories (CIR) (or Technical Information Repositories (TIR) pre-Issue 4.1). But these are limited to specific kinds of information such as parts information, common warnings and cautions, functional item numbers, etc., for which the specification has defined a CIR. DITA still has more granular reuse, because with the conref mechanism and XInclude, you can reference just about any element in any document. Although XInclude is not specific to DITA, the S1000D schemas do not allow the use of it as of the latest issue (4.2).

CIR example:

You have a common part called the "ABC connector". Your parts repository contains details about it:

<partSpec>
<partIdent manufacturerCodeValue="12345" partNumberValue="ABC"/>
<itemIdentData>
<descrForPart>10 mm ABC connector</descrForPart>
<partKeyword>connector</partKeyword>
<shortName>ABC connector</shortName>
</itemIdentData>
</partSpec>

In a procedural data module where this connector is required as a spare part, instead of duplicating the above information, you can reference it:

<reqSpares>
<spareDescrGroup>
<spareDescr>
<partRef manufacturerCodeValue="12345" partNumberValue="ABC"/>
<reqQuantity>1</reqQuantity>
</spareDescr>
</spareDescrGroup>
</reqSpares>

This data module is said to be CIR-dependent because it only contains a reference to the part. You have two main options for delivering it:

Resolve the CIR reference by copying the information from the parts CIR in to the data module. This could be an automated process at publish time, for example. Afterwards, the data module is said to be standalone.
Distribute the CIR with the data module. This is more common when you're publishing to an Interactive Electronic Technical Publication (IETP) viewer that can fetch the information from the CIR at run-time.

---

(0)

Login to post a comment!