Posts Tagged‘DMC’

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

How to Get the S1000D Answers You Need

The majority of the traffic on the Crowell Solutions’ website is visits to our S1000D informational pages.  Our S1000D Glossary and S1000D Introduction pages consistently get the highest number of visits. One thing that means is that a lot of Crowell visitors are looking for information — and answers — about S1000D.

We know that, when you are new to S1000D, getting information from the specification is like drinking water from a fire hose. If your organization is thinking about moving to S1000D, it is hard to figure out *whether* and *how* to implement S1000D.

You are most likely looking for answers to *your* questions. The faster, the better. The easier to understand, the better. So here’s an offer: talk to an S1000D expert right away. Contact us and we’ll set up a phone conference ASAP. During this meeting you set the agenda and you drive the meeting. We will answer any S1000D questions you have. For more information, click here.

–Don Smith

CapStone™ S1000D Productivity Suite

As I mentioned in our last blog, we are in the process of developing a new S1000D productivity Suite called CapStone™. CapStone represents what we are referring to as the “second generation” of S1000D applications. The first generation of tools were worried about storage and retrieval of documents. While storage and retrieval is indeed important, it is a fairly trivial challenge in the IT world. In order to make an S1000D environment truly robust and usable, additional features are required. CapStone will include the following individually available components:

  • DecisionPoint™ – For Business Rules Management and BREX generation
  • DMRL Manager
    • SNS management
    • Information code management
    • DMC (Data Module Code) component management
    • DMRL (Data Module Requirements List) management and generation
  • Applicability Manager
    • ACT, PCT, and CCT management
    • Field updates
  • Publication Manager

An interesting feature of CapStone is that it can sit on top of any existing S1000D CSDB, or database (Oracle, SQL, etc.). If you have a site license for Oracle and want to turn it into an S1000D CSDB…great! If you already have a first generation S1000D CSDB and need a more robust environment to make it work the way you need it, CapStone will fit the bill. In addition, we are building integrations to other “S” Standards, including:

  • S3000L
  • S2000M
  • S4000M
  • S5000F

We anticipate debuting CapStone™ S1000D Productivity Suite at the AIA-Joint Services Technical Publications workshop, May 12-13 in Clearwater, FL. We hope you will join us. We also plan on attending the S1000D User Forum, June 6-8 in Montreal, CA. Of course, if you want a preview before then or are interested in becoming one of the first customers, contact us and we will make it happen!

–Rick Schochler

S1000D: Why NOT to Use Pseudo Data Module Codes

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:

data module code

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.

-Rick