Posts Tagged‘data modules’

Using S1000D Architect

describe the image

We have implemented quite a few S1000D applications over the past few years and this experience led to the creation of S1000D Architect. Many S1000D applications that are on the market today are focused on the storage of data modules via a CSDB. While this is very important, equally (or maybe evey more imporatant) is how the S1000D program is managed. What we mean by that is:

  • How do you create data modules?
  • How do you insure you’ve created all the data modules you need?
  • How do you manage creating DMRLs and SNS structure?
  • How do you manage the project(s) itself as well as the people assigned to the project?

We have addressed each of these critical issues within S1000D Architect. Request our whitepapers and, by all means, give us some feedback!

How about a little BREX 101 this week?

One of the most common points of confusion I hear about in the S1000D industry is concerning what the BREX data module does and how S1000D business rules are used to generate a BREX data module. It is believed by some that a BREX DM contains all of the business rules for a program, and by handing a BREX to a partner company, you can effectively instruct them on how to develop S1000D to conform to your business rules. 

This is not completely accurate. A BREX document is really only capable of storing rules that are enforceable on the actual S1000D XML content. This is due to the fact that a BREX rule must be enforced via an XPath statement. Decisions pertaining to the use of optional elements are perfect examples of S1000D business rules that exist in, and are enforced by, the BREX.

Rules governing the overall usage of S1000D cannot be enforced or expressed in the BREX data module. Examples of such rules include:

  • the decision to use process data modules instead of the fault isolation data module, or
  • to use an Arial font instead of Times for chapter titles.

Although these are important rules, they cannot be expressed using an XPath statement and, thus, are not included in the BREX document. 

When conducting training classes or when explaining S1000D constructs to our customers, we have found it useful to think of S1000D business rules as consisting of two distinct categories:

  1. Program Rules
  2. Authoring Rules 

A program rule is an S1000D business rule that dictates specific usages of the standard that does not specifically address XML content. Program rules include rules such as graphic formats, CSDB configuration, type of data modules to be used, etc. As program rules are meant solely for human use, these are generally provided as documentation (a Word file, HTML, etc).  

Authoring rules are data oriented and can be expressed as an XPath statement and, as such, can be enforced by a program or software application. The decision to disallow an optional element can be enforced via an XPath statement, and thus should be included in your BREX document. It is then the duty of a BREX-aware processor to read the BREX document and enforce these authoring rules.

So, when exchanging business rules, it is important to not only exchange your BREX data module, but supporting documentation containing program rules as well.

Any questions? Give us a call!

–Eric Lawson

BREX Data Module: What, Why, Who, When, Where & How

What?

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.

Continue Reading

S1000D: The Simplest Explanation Ever

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.

–Rick