DITA for Publishers with Eliot Kimber

For this month’s Central Texas DITA User Group meeting we played host to Eliot Kimber. I took some scattered notes, mostly jotting down the great phrases Eliot handed out while nodding and chuckling.

He’ll be doing this presentation as a webinar for Really Strategies, Inc. on March 10th, 2010 and you can sign up on the Really Strategies website.

Eliot is explaining why DITA makes sense for publishing outside of tech comm – because most all publishers need to get ePub out of their legacy content. NEED.

DITA should take over everything – Eliot has an evil plan. He tries not to put his pinky to his chin, though. He uses strong statements, though, like:

“No reason to choose any other XML standard but DITA.”

DITA for Publishers is built on/with/using:

  • Topic types: article, chapter, subsection, sidebar, part
  • Map domain: pubmap
  • MS Word to DITA framework – XSLT-based framework
  • ePub transform for Open Toolkit
  • Pubmamp support for PDF transform, which enables creating quick drafts for review while people offshore the XML-izing of the content

Example of just how exacting and demanding editors at publishers can be: Quark to Indesign migration blocker (years ago) was that a particular hyphen character wasn’t automatic with Indesign.

Eliot on publishers deciding to go with XML: “If they’re really lucky, they have an IT group that won’t help them with decisions on XML solutions.”

What Publishers need that DITA brings: (bold emphasis mine)

  • Low cost of entry for sophisticated XML solutions
  • Blind interchange of content
  • Flexible markup design
  • Strong support for modularity and reuse
  • Wide support by free and commercial tools

He got tired of reinventing the same thing over and over – DITA for Publishers makes his implementation job easier – more clients farther along a path of success.

Doesn’t DITA require modular writing?
- No

Most people implementing DITA have one topic, one file – but that is not necessary – he could have an entire book as a single XML document with one root “topic.”

Who’s using DITA for Publishers?
- ASTD is using it for their publishing of books and magazines
- Upper Room – Methodist church – publishing arm of major No. American church for books and magazines
- Publisher of test preparation manuals – including TAKS test – using learning and training specializations for test questions as well
- Any Really Strategies client who doesn’t already have schemas (or who is willing to migrate to a DITA-based solution)
He usually can get at least one output that they can’t currently get out of their current XML schemas

Publications are very simple – except when they’re not. One differentiator that publishers can use is the design of the book – unique, attention-getting designs are valued.

DITA enables iterative design and development – when you come across something more sophisticated than the “norm” you just keep adding features – and interchange is always ensured.

Map / Content distinction is essential – chapter, sections, subsections, but publication structures can be very complicated with appendices, glossaries, indexes. Maps can impose the semantic meaning within the context of a map structure. So you may have one kind of division element, but 18 kinds of topic reference (yow, but that makes sense.) Means he can convert easier to generic topics, but add sophistication through the map.

Lots of publishing content is highly modular -

examples:
magazine articles – reusable, valuable, can send through email, post to web
encyclopedias
travel and nature guides – can be recombined in interesting ways to provide additional value – also batch consistency over a large number of pubs makes sense (automated composition is a-okay)
Dictionaries
Newspapers
Sidebars – by its nature it’s a standalone thing
Educational materials such as textbooks
Standards – people make money publishing info about accounting standards, for example

Business rules apply to element types in their CMS – so there’s a practical aspect to article, chapter, subsection, sidebar and their nesting

Bookmap is way too limited for technical manuals that don’t conform to IBM standards

Bookmap doesn’t give publishers what they need, so he built a publication map domain – provides more structuring options, more licensing options (nothing to do with copyright), he can also mix it in with other map domains, e.g. learningMap

structural module vs domain module – you can pick and choose in a domain module the things that are specifically useful

Provides publishing-specific structures, such as “page” – can have a topic with an empty title element

Publishing domains:
+ Formatting domain
- supports capturing of arbitrary formatting (example: 9th grade biology text book – lots of nutty formatting)
- Integrates MathML
-Can embed raw InDesign interchange data
+ Pub content domain – elements contained in typical publications, e.g. epigram
+ Verse domain: markup for poetry
+ Classification domain: container for classifying metadata (specific taxonomy, Upper Room has this for all the ways their content relates to the domain of spiritual “stuff” he used a DITA map for the taxonomy)

General purpose Docx to DITA XSLT transform – authors are writing magazine articles in Word and then submitting. Transform configured by separate style-to-tag mapping. Everything from magazine articles to entire course scripts, all with different configuration parameters. Must have consistently tagged styles in the Word document.

XML-first workflows are pretty rare in the publishing industry among publishers.

Too much variablity in the business process – eight different biz processes through which they get books to publish at an association, for example.

Typify can “remember” where things came from and automate composition, but it costs a bunch.

DITA to InCopy generates InCopy articles from DITA topics – InCopy is used for manuscript preparation (writing with no layout).

The ePub open toolkit plugin generates HTML-based ePub packages from maps
Uses output of the base XHTML transformation type

What he wants to continue after DITA 1.2 is done:
- Documentation of vocabulary modules
- Refinement and extension of tools an infrastructure

Community of DITA for Publishers users is building – he wants to propose it as a DITA Subcommittee once he gets enough community behind it.

6 Comments

  • Lisa Dyer
    February 25, 2010 - 11:27 am | Permalink

    Great writeup, Anne, as always — thanks! (Sorry couldn’t make it.)

    Eliot, sign me up for that sub-committee. Secret plan for world domination wants to join Evil plan;)

    - lisa

  • February 25, 2010 - 4:07 pm | Permalink

    It sounds like it was a great session. Thanks, Anne, for posting such extensive notes.

    Eliot has always had a knack for speaking the truth, even when it’s controversial. It sounds like sacrilege for him to suggest that DITA doesn’t require modular writing — but he’s right. While I wouldn’t recommend adopting DITA without also adopting modular writing, it need not be a barrier when DITA is the right solution for a business problem.

  • February 25, 2010 - 4:10 pm | Permalink

    This definitely wets my appetite for the upcoming webinar. I knew Eliot was working his evil plan and I haven’t had enough time to focus on what he’s been doing, but I hope I can get this message. Hopefully, I can wrap my webinar up in time to not miss a word of his.

    Nice summary Anne. Thanks a bunch.

  • Dorothy Hoskins
    April 17, 2010 - 10:49 am | Permalink

    Eliot has evidently put a lot of thought and effort into trying to make DITA work as originally designed for general use by publishers, and has decided it isn’t a good fit to make tons of little topics. Hence the “make one big topic and use sections” approach that he mentions. (The key publishing application that he targets is Adobe InDesign, which commands the majority of market share for high-end publication design applications.)
    Apparently, most InDesign designers are not sold on the value of having XML content in their files — generally they don’t yet understand why they should bother to learn about it. But there is one wave of InDesign and XML developers that DO get it — the overseas (mostly Indian) people working for major publishing companies, judging by the number of XML and InDesign-related threads in LinkedIn and other social media. So I think it behooves designers who work with InDesign here in the USA to find out more about its XML features, to be ready to compete in the job market, while we collectively work out the best way to use DITA in publishing.
    BTW, Adobe probably did not make any radical changes in InDesign CS5 XML handling capabilities — the CS5 release is out in May 2010, so we can find out more soon. Since CS3, Adobe has been focussed more on ePub, incorporating Flash, and other improvements to InDesign. FrameMaker is their flagship XML product and has advanced DITA support. Unfortunately, the InDesign users don’t want or need FrameMaker to do their work, so there is a split within the Adobe product set between InDesign features for XML (“just enough XML” –limited to handling import of fairly flat structures, generally, no ability to handle DITA conrefs or boookmaps) and FrameMaker (robust XML editing for tech docs, including conref support and bookmaps for DITA). Of course there is no “save as InDesign” from FrameMaker or vice-versa,.although the DITA XML files in theory are usable in either application.
    I think we’ll see more methods to get DITA content into InDesign to tap into the scientific and educational publishing markets in particular. You can mix XML and non-XML content in InDesign and make them look the same, including colors, fonts, unusual column layouts, etc.. Not a trick you can do with the DITA OT.

  • Pingback: DITA and novels–a hyper notion - Learning by Wrote

  • November 6, 2011 - 1:51 pm | Permalink

    Too bad I’m not in Austin – would have been a fun meeting. We’ve seen the results of D4P in practice, and they are good. Looking forward to contributing to the proposed subcommittee.

    Mike

  • Leave a Reply