- Knowing how many data modules comprise your S1000D project(s).
- Knowing where these data modules are coming from (your team, vendors, etc.).
- Managing multiple SNS schemes (yours, your vendors)
- Managing vendors’ data modules
- Ability to efficiently build a list of all necessary data modules
- Tying this list to a ‘stub-out’ of the data modules themselves (i.e., create a rudimentary XML document for each and every data module in your project).
Look for posts, additions to our website, and email notifications in the coming weeks. We are excited about these applications and rolling them out to general availability. If you want a sneak peek, contact us at firstname.lastname@example.org
The Business Rules Exchange Data Module (BREX DM) is used to programmatically enforce business rules that govern what can and cannot appear in an S1000D data module’s content. The BREX DM uses XPath statements that verify that authored content conforms to the project’s business rules. For example: to ensure consistency in the units of measurement used in a program a BREX rule could specify and enforce the use of only metric values.
Note: There are business rules that are defined by a project that cannot be enforced programmatically. Business rules that cover general policy (such as publishing to an IETM environment) are dictated in a Business Rule document, but are not part of the BREX.
Even the most ardent defender of S1000D has to agree that it has limits. It is a great specification for capturing complex technical data in a complex fashion. And, while long, the Data Module Code (DMC) is good at uniquely identifying S1000D data module content. I admit I still have to, on occasion, look up all of the components that comprise a DMC. For a more detailed explanation, visit our S1000D Glossary. For your reference, here is a quick explanation:
However, just as S1000D is not an ideal fit for someone creating a poem, a DMC is not a good means of identifying non-S1000D content. For example, using pseudo-DMCs while creating supporting content for the specification, including creating unique IDs for business rules is a bad idea. Pseudo-DMCs create additional complexity and do not provide additional value in return. Using a simpler ID syntax provides all the capabilities you will need. The methodology we use is simple: take the chapter from which the rule came and append a -1, -2, -3, etc. (e.g. 3.9.1-1 correponds to the first rule within chapter 3.9.1).
Based on our experiences, DMCs should be used solely in identifying S1000D data module content.