Category Archives: S1000D

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”)

The new Business Rules Document (brDoc) Schema, introduced in the S1000D Issue 4.2, possesses excellent potential, and I believe it will help reduce the duration and costs of the business rules production and maintenance as well as increase their quality.

But like any new construct in a standard and specification, it raises the question, “What is it good for?”

And when it comes to the S1000D business rules, especially the specification’s seasoned users will naturally ask such questions as, “Doesn’t the Business Rules Exchange (BREX) Schema, which was introduced earlier, already cover the business rules aspects?”

I have given answers to these questions from my point of view in the latest article for the Mekon’s Bitesize series on business rules.

Click the title of the article to find out more: “Understanding the Business Rules Document (brDoc) Schema.”

(Credits: Photograph ©librestock.com under the keyword “document”)

In the previous articles, I contribute to Mekon’s Bitesize articles on Business Rules, I mentioned about the importance of defining the business rules before signing contracts, and also about the sequence or order in business rules definition.

In the most recent article in this series, titled “Why Does It Make Sense to Generate a Business Rules Index First and a Guidance Document Second?”, I address the flow of business rules definition process in more detail, but especially the form of it.

In my opinion, it is much more sensible to have all business rules recorded as an index with all the necessary information and guidance attached to each entry, than to start with a flowing text, as it is usual for contracts and statements of work.

And above that, I think you should start with creating an index (before signing contracts) and keep it as a master knowledge base of all decisions, and then extract information out of it to create all the guides, the contracts, and statements of work.

You can find the reasons why I think so in this article here.

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