Skip to main content

Applicability

Applicability is the part of S1000D that lets one set of content serve many product variants and configurations. You write a procedure once. You mark which parts apply to which products. A tool then filters the content for a specific aircraft, vehicle, or serial number.

This is the source-once, use-many idea applied at a fine level. It works on a whole data module, and it works on small pieces inside a data module, such as a single step, a warning, or a table row.

Why it matters

Without applicability, a fleet of three engine variants needs three copies of every shared procedure. Each copy drifts over time. With applicability, you keep one master and let the system produce each variant on demand. Less duplication means fewer errors.

The two things you can filter on​

S1000D separates the data you filter on into two kinds.

KindWhat it isExamples
Product attributeA fixed property of the product. It does not normally change during the product life.Model, version, series, serial number
ConditionA state that can change over time or by environment.Service bulletin incorporated, climate, location of maintenance

This split is important. A serial number is an attribute. "Has modification kit 42 been fitted" is a condition. Both can decide whether content applies, but they are managed differently.

The three cross-reference tables​

S1000D declares the allowed properties and the real product instances in three cross-reference tables. Each is itself a data module stored in the CSDB.

AcronymFull nameWhat it holds
ACTApplicability Cross-reference TableDeclares the product attributes and their allowed values
CCTConditions Cross-reference TableDeclares the conditions and their allowed values, including condition types
PCTProduct Cross-reference TableLists the actual product instances and gives each one its attribute and condition values

The ACT and CCT act as lookup tables. They define what you are allowed to assert on and which values are valid. The PCT describes the real fleet: for each physical product instance, it records the value of each attribute and condition.

How they fit together

Think of it as a schema and its data. The ACT and CCT are the schema of allowed properties and values. The PCT is the data about each real product. The applic markup inside a data module then references identifiers declared in the ACT or CCT.

Applic elements: asserting what applies​

Inside a data module you tag content with applic markup. An applic statement says, in effect, "this content applies when these properties hold."

The building blocks are:

  • applic wraps an applicability statement.
  • assert is a single test. It names one property and the value or values to test against. It evaluates to true or false. It works like an equals check.
  • evaluate combines several assertions with a logical operator (and / or), so you can build compound rules.

Each assertion identifies the property in three parts:

PartMeaning
Property identifierWhich attribute or condition (a name declared in the ACT or CCT)
Property typeprodattr for a product attribute, or condition for a condition
Property valuesThe value, list of values, or range to test against

You only assert on the properties that actually matter for that content. If a step applies to every version, you do not tag it at all.

Illustrative example​

The following is a simplified, illustrative applic snippet. It marks content that applies when the product version is B or C and service bulletin SB-1234 has been incorporated. Real markup uses the full S1000D schema attributes and references identifiers declared in the ACT and CCT.

In applicPropertyValues, a pipe (|) separates a list of discrete values (so B|C means "B or C"), while a tilde (~) denotes a continuous range (for example 1~3).

<!-- Example only — simplified for clarity -->
<applic>
  <evaluate andOr="and">
    <assert applicPropertyIdent="version"
            applicPropertyType="prodattr"
            applicPropertyValues="B|C"/>
    <assert applicPropertyIdent="sb1234"
            applicPropertyType="condition"
            applicPropertyValues="incorporated"/>
  </evaluate>
</applic>

Filtering in practice with s1kd-tools​

The open-source s1kd-tools toolchain can apply applicability filtering to produce a customer- or product-specific instance of a data module or a whole publication.

The s1kd-instance tool produces a filtered "instance" of CSDB objects. The example below comes from the tool's own documentation. It filters content down to product version B:

# Example from the s1kd-tools documentation — filter one data module for version B
s1kd-instance -s version:prodattr=B <DM>

# Filter many objects into an output directory for "customerB"
s1kd-instance -s version:prodattr=B -O customerB DMC-*.XML

In those examples, -s sets the filter criterion (property:type=value) and -O sets the output directory.

The s1kd-appcheck tool checks applicability. It can report product attribute or condition assignments that would make a data module invalid after filtering, which helps catch broken applic markup before publishing.

Keep applic rules close to the BREX

A project's business rules say which attributes and conditions are allowed and how they are named. Those rules are encoded in the project's BREX data module. Aligning your ACT and CCT identifiers with the BREX keeps applic markup consistent and machine-checkable across the whole CSDB.

Summary​

  • Applicability lets one content set serve many variants and configurations.
  • You filter on product attributes (fixed) and conditions (changeable).
  • The ACT declares attributes, the CCT declares conditions, and the PCT lists real product instances and their values.
  • Inside content, applic markup uses assert and evaluate to state when content applies.
  • Tools such as s1kd-instance and s1kd-appcheck apply and validate the filtering.

Sources​