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.
Concurrent with the Joint Services S1000D Workshop being held at the Gulf Coast Community College in Panama City, Florida, Crowell Solutions will be present in Panama City Beach. Rick Schochler and Don Smith, Ph D., will be staying at the Holiday Inn Resort. Rick and Don are interested in meeting with other S1000D practitioners and discussing the issues and challenges of real-world S1000D implementations, such as:
- S1000D Business Rules
- S1000D Systems
- S1000D Training
- S1000D Best Practices
In addition, Rick and Don can discuss the industry leading application for developing and managing S1000D business rules, DecisionPoint™.
If you want to chat with two people who have been in the “S1000D trenches” shoot us an email at email@example.com or firstname.lastname@example.org, or call either Rick at 817-999-2258 or Don at 214-264-7136. You can also catch our twitter updates by following us @crowsol.
We look forward to seeing you in Florida!
At a company that I once worked for (I won’t name names, but they once enjoyed a good reputation in the SGML/XML world), we developed and marketed a process for how data moved through a system, from creation to distribution. It served as a very effective tool for explaining to our customers exactly what we did and why our services were valuable.
I think a similar approach is needed for detailing the activities in instantiating an S1000D-based system. I’ll come up with a fancy term such as “S1000D Process” – see Mom, all my years of schooling are finally paying off!
The S1000D Process:
We have identified six components of the S1000D process:
- Determine which version of S1000D you are going to use.
- Identify content to be managed.
- Determine data module granularity.
- Determine publishing strategy (electronic, print, both).
- Complete the Functionality Matrix available from the S1000D website.
- Business Rule Definition
- Detail your S1000D business rules.
- Determine which rules can and should be enforced by the BREX.
- Generate or develop your BREX document.
- CSDB Selection
- Determine which tool best fits your organization’s needs.
- Decision is based on S1000D version, existing infrastructure, desired functionality and, of course, $$$.
- Note this right off the bat: You WILL need customizations.
- CSDB Implementation
- Integrate with existing systems.
- Develop customizations to fulfill the totality of your requirements.
- Coordinate with engineering.
- Technical writers are creating content utilizing S1000D schemas and the appropriate BREX document.
- Create illustrations.
- Publishing and Distribution
- Publish to electronic and/or print.
- Distribute worldwide!
At this past year’s AIA conference in lovely Clearwater, Florida (that’s not sarcasm, Clearwater is awesome…especially the SandKey Marriott…hey, maybe they’ll throw some points my way for this endorsement!) a speaker asked for a simple explanation of S1000D.
OK, here goes:
S1000D is a specification for creating and managing technical data in a modular format called “data modules”. Data modules are best described as one complete thought or process. This might be a description of a tool, or a subtask in a larger task. By creating this content in modular form (as opposed to traditional cover to cover technical manuals), content can be reused as many times as necessary. S1000D uses XML Schemas to control what can and cannot be found in data modules. There are several different types of data modules catering to content ranging from descriptive to procedural, to illustrated parts data and scheduled maintenance. S1000D is ideally suited for large-scale manufacturing and repair environments.
There. A simple explanation of S1000D. It occurs to me that S1000D is somewhat akin to baseball (though not as fun). Just as baseball is a simple sport to explain but a hard one to master, S1000D can be simply described, but the details of how it all works may take a LONG time to master.
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.