keep calm and specialize your content model
TRANSCRIPT
Who am I?
Chris Nitchie
Lead Product Developer at Oberon Technologies
Formerly of PTC/Arbortext
DITA TC Voting Member since 2009
15 years' experience in XML authoring and publishing
Benefits of Markup Standards
Lots of standardized grammars out there -DocBook, S1000D, ATA, MilSpec, etc.
Facilitates information interchange between organizations.
Built on shared experience of common content requirements - you don't have to do it all yourself.
Pitfalls of Standard Grammars
Least common denominator.
Addresses generic requirements, but not all of your organization's specific needs.
So You "Fix" It
With many standard grammars, there's a way to customize it to suit your needs.
Some groups might choose to build their own DTD/Schema from scratch. (Don't be that group.)
But now you're no longer interchangeable with other organizations using the standard.
Migration to new versions is much more challenging.
You're on your own.
Enter DITA
At Its Core, DITA is Three Things
1. Topic-based content architecture.
2. Base grammar/tag set.
3. SPECIALIZATION.
Benefits of Specialization
Your markup matches your content requirements.
DITA processors can handle the base vocabulary if they don't know about your specializations.
So interchangeability is preserved.
In short: It's Still DITA.
Base DITA Vocabulary is Basic
Paragraphs
Lists
Notes
Figures
Sections
Tables
Phrases
Terms
Cross-references
Graphics
Basic metadata
A few other things
You Use Specializations Already
<ph>
<b>
<i>
<u>
<topic>
<concept>
<reference>
<task>
<topicref>
<topichead>
<topicgroup>
<keydef>
<ol>
<steps>
<li>
<step>
How Specialization Works
You can create your own markup.
It must be based on, and compatible with, the base vocabulary.
The @class attribute identifies the "parent" tag.
DITA tools will fall back to processing/styling of the parent automatically.
You say:<steps><step><cmd>Identify content requirements.
</cmd></step><step><cmd>Specialize!</cmd>
</step></steps>
DITA processors see:<ol class="- topic/ol task/steps "><li class="- topic/li task/step ">
<ph class="- topic/ph task/cmd ">Identify content requirements.
</ph></li><li class="- topic/li task/step "><ph class="- topic/ph task/cmd ">Specialize!
</ph></li>
</ol>
Constraints!
Removes tags from a tag or tags defined elsewhere.
E.g. strict task.
Can greatly simplify authoring environment by eliminating unneeded tags.
Can also force stricter structural rules than the base vocabulary.
Easiest kind of specialization to develop.
No, seriously. Do this.
Element Domains
"Mix-in" tags that can be integrated in any DITA doctype shell.
Based on existing elements.
Address specific use cases.
For example:
Highlight domain (b, i, u, etc.)
Software domain (msgblock, varname, etc.)
Structural Specializations
The top-level document"container".
Mandates the overall structure
Examples: Concept
Reference
Task
Bookmap
Attribute Domains
Custom profiling or metadata attributes.
E.g. @outputTarget(DITA 1.3 improvement on @print).
DITA Doctype Shells
Ties all this together
Combine structural specializations, element domains, constraints, and attribute domains to define the actual document grammar.
When NOT to Specialize
One-off or rare special processing.
Use @outputclass instead.
When the base vocab or an existing domain will serve.
Do some analysis and research before diving in.
Identify the gaps before you fill them.
How to Specialize
First, you have to design your specialization.Don't even think about coding it up until you know exactly why you need it and how you'll use it.
Then, you have to code it. This is non-trivial, even for professionals who know what they're doing.
So, this is the bad news. It's pretty hard.
DITA 1.3 Helps
RelaxNG makes things easier.
Many of the rules for developing specializations in DITA 1.2 have been relaxed in 1.3.
Lots of community activity trying to simplify the process.
You Know Your Content
Nobody knows your content needs and requirements.
DITA lets you define structures that match your requirements while staying on the standard.