- 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
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.