Documentation Center

BREX Validation Overview

When you validate a module against its BREX, the tool validates rules that can be validated programmatically.

A BREX rule that can be validated programmatically contains an expression that matches one of the following conditions.
  • The expression is not allowed in the data module.
  • The expression is required in the data module.
  • The expression is required and contains an attribute or tag contents that must match a permitted value.
  • The expression is optional and contains an attribute or tag contents that must match a permitted value.

BREX rules that do not meet one of the above conditions cannot be validated. Rules that cannot be validated are noted in the BREX compliance report.

The BREX Validation tool cannot detect layered business rule conflicts. Lower level BREX rules must be authored with care to ensure that business rules in the lower (child) layers adopt or conform to the business rules of the higher (parent) layer.

BREX rules that can be validated programmatically

The Content section of a BREX data module contains three main blocks of business rules that govern how an S1000D project should work: SNS related rules, context related rules, and context independent rules. The Contenta S1000D Validate tool is able to programmatically validate context related BREX rules. Context independent rules must be validated by a human.

The following table contains selected BREX rules that can be validated by the S1000D Validate tool.
BREX Rule
Notes are not allowed in Warnings.

XPath expression of the rule (3.0 markup):

<objpath objappl="0">//note[ancestor-or-self::warning]</objpath>

RFU must not be used on Issue 001 of a data module.

XPath expression of the rule (4.0 and higher markup):

<objectPath allowedObjectFlag="0">

//identAndStatusSection/dmAddress/dmIdent/issueInfo

[attribute::issueNumber = "001" and ancestor::dmodule[child::identAndStatusSection[child::dmStatus

[child::reasonForUpdate]]]]</objectPath>

Attribute learnEventCode - used to store the learn event code.

XPath expression of the rule (4.0 and higher markup):

<objectPath>//@learnEventCode</objectPath>

Permitted values:

<objectValue valueForm="single" valueAllowed="A">Learning plan</objectValue>

<objectValue valueForm="single" valueAllowed="B">Learning overview</objectValue>

<objectValue valueForm="single" valueAllowed="C">Learning content</objectValue>

<objectValue valueForm="single" valueAllowed="D">Learning summary</objectValue>

<objectValue valueForm="single" valueAllowed="E">Learning assessment</objectValue>

BREX rules that cannot be validated programmatically

The following table contains selected BREX rules that cannot be validated by the S1000D Validate tool.
BREX Rule
Editorial changes must not be marked.

XPath expression of the rule (4.0 and higher markup):

<objectPath>//@changeMark</objectPath>

Explanation: This rule requires a person to determine if the change was editorial or substantive.

The element /changeInline/ must not be used to indicate that a complete element has been inserted (or modified).

XPath expression of the rule (4.0 and higher markup):

<objectPath>//*/changeInline</objectPath>

Explanation: This rule requires a person to determine if a complete element was added or modified.

Sequential lists must not be used to provide procedural step information.

XPath expression of the rule (4.0 and higher markup):

<objectPath>//proceduralStep[descendant-or-self::sequentialList]</objectPath>

Explanation: This rule requires a person to determine if a particular sequentialList in a proceduralStep is valid or not. Note that if the XPath expression's objectPath tag was <objectPath allowedObjectFlag="0"> rather than <objectPath> , this rule could be validated programmatically because sequentialLists in proceduralSteps would simply not be allowed at all.