There is hardly an S1000D implementation without BREX today. Check out my past month’s contribution to the Mekon’s BR Bitesize series to find out what BREX is and isn’t. Click on the title of the article “Let’s Talk About BREX” or here to find out more.

(Credits: Photograph ©canva.com with the keyword exchange)

Apart from business rules decision points and decisions which are to be taken, you need also to record whether the decision is finalized, or whether there are open actions in their respect. You also have to define the deadlines and the responsibility for those actions.

All that and some other information is recorded in the brAudit element of the new brDoc Schema, defined in Issue 4.2.

In the past month’s contribution to the Mekon’s BR Bitesize series, I addressed this element and the concepts behind it in the article “brDoc Schema: What is Business Rule Audit (brAudit) about?” Click on the title of the article or here to find out more.

(Credits: Photograph ©canva.com with the keyword audit)

At least 90% of the brDoc (business rules document) Schema introduced in S1000D Issue 4.2 is based on the well-known descriptive Schema.

The new 10% which comprise the business rules paragraph (brPara) element and its components are mostly self-explanatory. But some elements might need additional explanation to be understood because their names cannot fit all dimensions of what they mean now and might mean in the future when further developed.

That applies to the element brRelatedTo, which is defined as business rule decision point relationship in Issue 4.2.

In the past month’s contribution to the Mekon’s BR Bitesize series, I addressed this element and the concepts behind it in the article “brDoc Schema: What does brRelatedTo stand for?” Click on the title of the article or here to find out more.

(Credits: Photograph ©canva.com with the keywords business relationship)

When you read an earlier issue of S1000D, you come upon a question disguised as an affirmative sentence, stating what a project has to do. But you still recognize it as a question, which you have to answer when defining a business rule. Since the Issue 4.0, these are even more distinguishable since they start with the words Business Rules Decision Point.

But when you look at the new business rules document (brDoc) Schema, defined in the S1000D Issue 4.2 you will see that there is a construct to markup a business rules decision without a decision point preceding it. What does that one stand for?

In this month’s contribution to the Mekon’s BR Bitesize series, I address this feature in the article brDoc Schema: Why is there a brDecision Occurrence outside of the brPara? Click on the title of the article or here to find out more.

(Credits: Photograph ©canva.com under the keyword decision)

One of the main purposes of the most of the S1000D Schemas is to standardize already available practices in the production processes of technical publications, and with that allow information’s reuse, interchangeability, and interoperability.

The business rules document (brDoc) Schema in S1000D Issue 4.2 is not an exception.

Many elements and attributes of this and other S1000D Schemas (for the latter starting with the Issue 4.0) have self-explanatory names. Take for example the elements dmCode, dmTitle, or attribute names securityClassification, brDecisionPointUniqueIdent and other.

However, some of the names of some of the core components of the S1000D Schemas need explanation.

That is also true for the major component of the brDoc Schema, the business rules paragraph (brPara).

In this month’s contribution to the Mekon’s BR Bitesize series, I have explained what a business rules paragraph is, and why the S10000D Business Rules Working Group (BRWG) has developed such a structure.

Click the title of the article to find out more: “brDoc Schema: What is a Business Rules Paragraph (brPara)?”

(Credits: Photograph ©canva.com under the keyword “paragraph”)