Sustainable XML for Publishing Applications: DITA Makes It Possible

Sustainable XML for Publishing Applications:

DITA Makes It Possible

Eliot Kimber, Really Strategies, Inc.

DocTrain East 2008

Who Is This Talk For?
 Publishers who want to implement XML-based
solutions
 Publishers who have XML-based solutions that need
to be enhanced, refined, or upgraded
 Creators of XML-aware tools applicable to publishing
use cases
 Service providers who support the development and
use of XML-based solutions for Publishers:
 Integrators
 Data conversion houses
 Consultants

DITA for Publishers DocTrain East 2008

About Me
 Senior Concept Prover at Really Strategies Inc.
 20+ years experience with generalized markup
(GML, SGML, XML, etc.)
 Career focus on large-scale hyperdocument creation
and management
 Focus for last 8+ years on Publishing use cases
around XML-based publishing workflows
 Active member of the DITA Technical Committee
 Founding member of the XML Working Group
 Long-time member of the XSL-FO Working Group
 Co-editor of the ISO/IEC HyTime standard


Audience Survey
 Who is here?
 Publishing for profit?
 Publishing as a cost?
 Technical Documentors?
 Service providers?
 People just interested in DITA?
 DITA knowledge:
 No idea what DITA is?
 Know about DITA a little?
 Familiar with DITA concepts and details?
 Using DITA now or implementing DITA-based solution?


What Is DITA?
 OASIS Open Standard: Darwin Information Typing
Architecture
 An XML architecture standard for representing
human-consumed information
 Some distinguishing aspects of DITA as an XML
architecture:
 Formal mechanism for controlled definition of new
vocabularies (“specialization”)
 Optimized for information modularity (“topics”, “maps”) and
blind interchange
 Standardized document type implementation design patterns
 Growing off-the-shelf processing infrastructure
 Sophisticated hyperlinking features (“relationship tables”)
 Currently at version 1.1, version 1.2 in final stages of
review and approval
7 DITA for Publishers DocTrain East 2008

Key DITA Concepts Briefly Explained
 Topics
 Topic content is paragraphs and stuff
 Standalone units of information
 Topics may directly contain other topics
 Maps
 Hierarchical sets of links to topics
 Establish organizational hierarchies for sets of topics
 May have many maps over the same topics
 Can impose metadata onto topics
 Can impose topic-to-topic hyperlinks (relationship tables)
 Specialization
 New element types are “subclasses” of existing types


Oooh, A Picture
Maps Topics

Map One

Topic Topic
A D

Topic Topic
B E

Map Two
Topic Topic
C F


Output Results

Map One I. Topic C
1.1 Topic B
1.1.1 Topic A
1.1.2 Topic D
1.2 Topic F

Map to
PDF
Map Two
I. Topic F
1.1 Topic B
1.2 Heading
1.1.1 Topic A
1.1.2 Topic E


Specialization
 DITA standard defines a set of base element types:
 Topic, map, section, paragraph, figure, table, phrase, data
 All other elements based on these base types
 Establishes a formal class hierarchy for all element
types in any DITA document
 Every element type maps back to some standard-
defined base type
 Declaration mechanism is formal and simple:
 Uses element attributes (“class=“)
 Can be processed by almost any XML tool, including CSS
selectors
 Even works for DTD-less documents


DITA Compared to Other XML
Options

Compare DITA With…
 DocBook
 Book-focused (not inherently modular)
 Can use XInclude to manage information in modular fashion
 No facility comparable to DITA maps
 Mature standard
 Very large tag set reflecting union of wide set of requirements
 No formal vocabulary extension mechanism
 Blind interchange not really possible
 Deep off-the-shelf infrastructure


 NLM
 Optimized for journals not books
 No formal vocabulary extension mechanism
 Little off-the-shelf infrastructure


 PRISM/PAM
 Essentially XHTML with sophisticated metadata
 Optimized for serialization, not authoring and archiving
 Little off-the-shelf processing infrastructure


 Custom XML application
 Expensive to develop and maintain
 Can be optimized for local requirements
 Processing infrastructure must be built from scratch
 Content management
 Authoring tool configuration and customization
 Publishing pipelines
 Interchange transforms
 No blind interchange possible


About That…XML Application Development Costs

 Information requirements analysis is always required
 Using a standard XML application still requires that
you determine how to apply it to your requirements
 All useful standard XML applications…
 …Provide more stuff than you need
 …Fail to provide some things specific to your requirements
 Amount of analysis required reflects your business
problem, not standard chosen
 Thus: cost of analysis is essentially invariant
regardless of implementation choice
 Main variable is cost of system implementation:
 Implementation of XML document types (DTDs)
 Implementation of management and processing


XML System Cost Analysis
 Three distinct cost domains:
 Initial system development
 Cost of use (training, skills required, cost of tools)
 Maintenance and refinement over long time scale
 Ideal implementation base minimizes all costs:
 Low cost of acquisition and implementation
 Low cost of use, skills and knowledge common in user
population, tools are appropriately priced
 Low cost of refinement, extension, interchange, management
 Cost evaluated in terms of value:
 Short term: ability to meet immediate requirements with
lowest initial cost
 Long term: ability to support new requirements with lowest
cost of maintenance and extension


DITA Largely Meets the Ideal
 Lowest possible cost of initial solution development
 Implementing custom doctypes very low cost
 Many off-the-shelf tools “just work” with little or no
customization or configuration
 Large and growing body of use-case-specific DITA modules
 Large and growing body of DITA knowledge
 Standard is well written
 Many service providers with solid DITA knowledge
 Growing body of published DITA how-to information
 Controlled extension (“specialization”) means:
 Knowledge about one DITA application transfers to all other DITA applications
 Extensibility and interchange are optimized
 Implementations can optimize their own modularity and flexibility


My Assertion: DITA Is Almost Always Best Fit
 DITA can be easily and practically applied to almost all
documentation use cases (not just tech docs)
 DITA’s unique features minimize initial cost of
ownership and implementation
 DITA’s unique features optimize interchange of
content
 DITA’s unique features maximize flexibility and
stability of supporting tools
 Therefore:
 DITA provides maximum value compared with other
alternatives
 Main cost is acceptance of a few constraints that enable
DITA’s value


DITA Myth One: DITA Is Only For Tech Docs
 DITA is a layered, flexible standard
 Originally driven by technical documentation
requirements…
 …but, core features are completely generic
 DITA has been used for:
 Government reports
 Financial standards
 Test preparation books
 Travel guides
 No inherent restrictions on the kind of publications
DITA will work well for


Forest for the Trees: It’s Still Just XML
 DITA has lots of cool features, some quite
sophisticated
 This sophistication can be scary
 But...
 …It’s still just XML
 You don’t have to use any particular feature of DITA
 Users don’t necessarily need to know it’s DITA
 If it being DITA-based doesn’t help at the moment,
don’t talk about it
 To the non-DITA-aware it looks like any other custom
XML application


DITA Myth Two: DITA Requires Topic-Based
Writing
 DITA standard is optimized for modularity
 But it does not require that content be stored or written as
modules
 Use of DITA maps is entirely optional
 Topics can physically contain other topics
 An entire book could be marked up as a single XML document
consisting of one root topic and many child topics
 Such a topic would be indistinguishable from any other similar
XML document (e.g., an NLM article, a DocBook document)


DITA Myth Three: DITA Is Hard
 DITA has lots of features, some quite sophisticated
 Making full use of all these features requires understanding
those features, of course
 But at its simplest, DITA is just like any other XML document
type for publications: sections, paragraphs, lists, figures,
tables, and inlines.
 Thus, a DITA application need only be as sophisticated as you
need it to be to satisfy your specific requirements
 Complexity and “difficulty” of DITA is concentrated in the data
processing requirements, not in authoring
 Ability to easily define custom vocabularies means you can
optimize markup names and structures to reflect local culture
and practice


In Short: Why DITA? Why Not DITA?
 DITA can be applied where any other applicable
XML standard can be applied
 At lower absolute cost
 With greater flexibility
 With greater potential value
 Cost of using DITA at worst no greater than using
XML generally
 So why not use it?


Yeah, But…
 I’ve said a lot of stuff
 What do you need from me to be convinced?


Publishing-Specific Challenges
 Existing vendor solutions and community knowledge
focused on tech doc requirements
 Many vendors don’t really get DITA
 Many tools don’t yet fully support specialization
 Many older tools limited by architecture and
implementation choices made years ago
 Many service providers still building understanding of DITA
 Publishing requirement for high-quality composition
always a challenge for any XML-based solution
 Publishers have different business drivers from tech
doc


Note to Vendors and Service Providers
 Potential market for DITA as a publishing solution
orders of magnitude larger than potential market for
DITA as a tech doc solution
 Many more publishers and units of publication than
tech doc producers
 Tech doc is a cost center
 Publishing is profit center
 In many ways, the value of DITA to publishing is
more compelling than it is for tech doc
 Just saying…


Publishing: Open Toolkit Alone Won't Cut It
 Pages are and will always be important
 Need a path from DITA XML to publishing tools
 InDesign
 Quark
 Etc.
 No technical barrier to a generic DITA-to-InDesign
process
 Products like Typefi could add significant value
 Several advantages for Publishers:
 Uses existing layout design skills, tools, and methods
 Can be 100% automatic or include human tweaking
 Can leverage Toolkit for preprocessing


Where Could Publishers Go From Here?
 DITA as specialized in the DITA spec not always
appropriate for Publishers
 Too constrained in some areas
 Needs more ways to capture format intent
 May not match existing publishing practice or conventions
well
 Might be useful to define a separate publishing-
specific specialization family rooted at DITA topic
rather than at concept/task/reference
 Can a novel be single topic or small set of topics?
[Yes]
 Does that help? Does it it hurt?


Business Process Improvement Implications
 Base cost of using XML is essentially unchanged
 Same challenges for legacy conversion
 Applying XML at end of process
 Using XML as input to revision process
 Cost of developing initial markup design can be
significantly lower
 Can have more generic, reusable processing
components
 DITA encourages and enables small modules
 Makes recombination at small granularity possible and
manageable
 Adapts well to delivery to portable devices.


Business Improvement Implications (Cont.)
 Incremental cost of DITA-based systems should go
down over time as infrastructure acretes
 Enables local optimization of markup without
impeding interchange within an enterprise or across
enterprises
 Provides controlled, formal framework for defining
common components used across parts of enterprise
or communities of interest
 Enables use of more sophisticated features as
needed


Potential Information Economy Improvements
 Reduce tight coupling between suppliers and
consumers (aggregators, republishers, etc.)
 No need to agree on rigid, overly-general standards
to enable interchange
 Supplier need not have full publishing infrastructure
in order to supply high-quality content
 Information consumers can apply a generic DITA
processing infrastructure to content from many
suppliers
 Increases value of information in DITA form
 Reduces impedance of interchange


In Conclusion
 DITA has lots of unique goodness of direct and
compelling value to publishers
 DITA can be used in simple ways to good effect with
low cost of entry
 DITA’s low cost and strong features represent a
compelling value for almost all XML-based publishing
use cases
 Full DITA infrastructure still being developed
 Off-the-shelf DITA-to-InDesign processes
 Standard publishing-specific DITA modules
 Community knowledge of how best to apply DITA to
publishing use cases


Questions?

?


Thank You

Eliot Kimber
Really Strategies
ekimber@reallysi.com


Sustainable XML for Publishing Applications: DITA Makes It Possible

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (6)

Semelhante a Sustainable XML for Publishing Applications: DITA Makes It Possible

Semelhante a Sustainable XML for Publishing Applications: DITA Makes It Possible (20)

Mais de Scott Abel

Mais de Scott Abel (20)

Último

Último (20)

Sustainable XML for Publishing Applications: DITA Makes It Possible