This presentation was one of the highlights of the conference for me, as most of the people responsible for driving the new DITA 1.2 specification were there to talk about what they had come up with.
Starting off the panel in the same way that he would normally be speaking with this group Don Day started off the meeting as if he were on the phone, and then asked for a roll call of all of the members who were there. I didn’t get the order right, but they are: Anne Bovard, Kristen James Eberlein, Joe Gelb, JoAnn Hackos, Erik Hennum, John Hunt, Gershon Joseph, Eliot Kimber, Frank Miller, Marc Speyer, Hal Trent, Su-Laine Yeo and of course Don Day.
They led off by saying that the previous general theme for DITA 1.1 was that of “book enablement” and that the follow-on DITA 1.2 specification can be characterized as being a “major step in overall features” — while still being fully backwards compatible — designed in part to reach new communities of users, and trying to fix some issues that came out of the previous version of the spec.
I managed to jot down the slide deck contents as they appeared on-screen, so here’s a summary of what was covered (along with my occasional running commentary in brackets):
Extended vocabulary:
- new learning and training elements
- new machine industry elements (“machine industry” being a synonym for “heavy equipment manufacturing” from what I could figure out; the hazard elements below is part of this)
- more glossary elements
- elements for acronyms and abbreviations
- meeting ISO/ANSI standards for hazard elements
- image scale-to-fit feature (I believe this is to let the writer specify the relative dimensions of an original image, not something akin to ImageMagick being implemented in tag-form as might otherwise be implied)
New/Improved reuse features
- keyref (a mechanism to make references to things that may not exist as yet; if I understand it correctly it like the opposite of a conref, in that it declares itself to be the target that is being pointed to rather than being some content that is being targeted. The best description that came out of this was that it is like a car navigation system that gets you part-way to where you want to go, then tells you to open the envelope on the seat beside you and then follow its directions to get to your destination;)
- conref ranges
- conref “push” (pretty much the opposite of traditional conref, it is the key that everything else wraps around it)
- new ways to group topics for reuse in DITA maps (map group elements)
Flexibility for Authors:
- generalized task model (much discussion on this point as well: the “strict” task topic we all know is still there, but a more generalized task topic now exists in 1.2, which allows the writer to put such things as <prereq> and <context> in any order (and to have any number of them). The same flexibility in the structural elements of a task can be applied to the end of a task as well, with the stated aim of making tasks more flexible. In addition, constraints are also available so that more specific sets of rules can be enforced by the DTD; in other words you can constrain which elements of the DTD are to be enforced. Steps now also includes a <steps-informal> element for handling use cases where there are more than one set of steps to troubleshoot a particular problem; this new element is in addition to <steps> and <ordered-steps>. You can now also have a warning note that appears before a step. <step-section> also allows the writer to put an explanation between steps (in other words: “if this happens, then do the following”). Note that the Document Architect can use general or strict task topic types but not both).
- recursive untitled sections (ensures that sections don’t get misconstrued as nested topics)
- keywords in keywords (can build complex strings in keywords)
- <text> element (its sole purpose is to be a generalized text reference within content)
Facilitate consistency within teams:
- constraints
- controlled values for metadata
- use the same specialized element in more contexts (domain/topic integration)
Maintainability/Housekeeping:
- catalog version numbers
- learning and training (part of the learning map domain: as a domain you can use these structures with any DITA map. You can mix and match your entry points from within the learning specialization. There are also domains for interactions, including question and answer structures; open questions, true/false and other quiz formats are included. Also, there are specific learning metadata elements included in the prolog.)
- metadata scheme (lets the Document Architect select the types of metadata values)
- glossary (it was explained that the version introduced under the DITA 1.1 spec just basically a “foot in the door”. It was missing features that would aid in localization (such as abbreviations); the new version is significantly improved and new tools for terminology management have been added).
- packaging (allowing the Document Architect to mix and match the elements from the new spec that are deployed for use).
There was concern expressed by a member of the audience that the specification may be getting too large and unwieldy; a reference was made to the S1000D specification running to over 3,000 pages in print, making it larger than any one person can encompass and hope to understand. This concern was noted by the members of the panel, though it was also pointed out that the new DITA 1.2 spec fully printed out ran to just over 1,000 pages.
Several of the panelists also mentioned that there is extensive information on many of the new elements and features on the dita.xml.org site; several articles are there already and can be searched for.
This panel discussion was one of the highlights of the conference so far for me, packed with lots of information and hinting at considerably more. Safe to say I’ll be digging into the new specification in order to better understand its workings.
