This page presents the results of the SWOT (Strengths, Weaknesses, Opportunities and Threats) analysis for DITA, conducted by OASIS DITA Adoption TC.
- Target the strengths to specific audiences -- Corporate audience include content creators, IT architects, and corporate leaders -- Vendor audience include localizers, tools vendors
- Benefits of architecture, toolkit, localization, and other major categories of strengths
- Significant body of research from MIT, IBM et. al. over many years resulted in DITA
- Minimalist, single source, reusable, cross-platform publishing workflow for structured content
- DITA enforces structured authoring for consistency and quality
- DITA offers a topic-based, rather than a book-based approached to authoring, encouraging reuse of content among multiple deliverables
- Separation of structure, content and presentation
- DITA Open Source Standard adopted by OASIS
Continued support to open source community from IBM - structure & tool- kit
- Multiple XML grammars are available -- RelaxNG, DTD, and Schema
- Multiple options for specialization are available -- structural, constraints, shells, and domain vocabularies
The toolkit approach provides a very flexible model for building all kinds of documentation systems, integrating with other XML technologies, e.g. XLIFF, MathML & SVG, and enabling dynamic content publishing & DITA based Wikis, for instance
- DITA Maturity Model - start off simple, expand as needed
- Adopted by many corporations, many of which also support community
DITA resources abound! Cf. Brenda's & Kristen's recent resource lists.
- Because it is XML-based, DITA is easy to localize thereby helping to reduce translation costs and promote translation efficiency
OASIS TC work in support of translations/localisations & broader business content semantics, e.g. XLIFF
Expansion into learning and training, & other industry specific initiatives
Supported by open source tools, tool vendors & consultants
- Protection from vendor lock-in
- DITA has achieved a huge mind-share in TA/TC communities
- DITA can support sharing content across entire industries - or at least vertically, between customers-companies-subcontractors
- Builds upon the benefits of the SGML architecture
- DITA Open Toolkit provides a standard for how DITA must be processed and ensures exchange with other content creators
- DITA editors available today are powerful and usable
- DITA enforces a level of consistency at the topic markup and map assembly levels that promotes quality information architecture
- DITA domain vocabularies for specific fields of writing immerse writers in that genre, whether it be tech comm, API, learning and training and so on.
- The DITA inheritance hierarchy provides reasonable default processing for specialized elements lowering implementation costs as a result.
- Key requirements: DTD/Schema, Toolkit, Instruction manual, user mailing list, etc. - from as many as 8 separate sites
- Toolkit is just that - a toolkit, not an application
- Exclusive reliance on the Open Toolkit may limit the use of DITA in special environments
- No content editing tool nor CMS included in toolkit
- Toolkit documentation is very poor, and also fragmented between different sites
- DITA adoption can seem more like a paradigm shift, with a steep learning curve and a complex solution
DITA adoption can appear to be a step backwards when migrating from the likes of Word or FrameMaker
- Requires not inconsiderable customisation, in several XML disciplines: ANT, CSS, XSLT, XSL-FO
- There is a significant geek factor to DITA
- Confusion relating to DTD and Schema - why include both?
- Many TAs don't have required skills and/or may not have access to required skills
DITA can be regarded as only being suitable for larger companies & corporates
Primary focus on computing needs - h/w & s/w
- Specialisation can be a red herring, especially in early stages of adoption
- The user experience with many content and map editors is awful and at best quirky
- DITA is perceived as very complex, only for XML specialists
- DITA is not seen by decision makers as a business solution, to business problems
- DITA is seen as something that only relates to tech.doc and/or technical authors
- When DITA is introduced, the review cycles can become much more bumpy because reviewers use other (non-DITA, non-XML) tools
- DITA is seen by the enterprise as a tech.doc. "black box" solution, not as an enterprise wide solution
- Confusion between DTD/Schema version numbering and Toolkit version numbering
- Updates to the standard happen very slowly
- Considerable lag time between an update to the standard and support for that update in the OT. Many users derive no benefit from an update to the standard until the OT supports it, and new elements and attributes that apparently "do nothing" are confusing.
- Perceived or real cost and complexity of migrating legacy content to DITA
- There is not much high-quality sample DITA content easily available. The samples that come with the toolkit are not great.
- Difficult to find well-explained worked examples
- Output using the Toolkit's default stylesheets Is Not Sexy.
- Interoperability requirements are not generally understood
- Paradigm shift for authors is considerable -- must have training in a new way of authoring
- Training required for technical support of the model and the output
OASIS DITA offers no test suite for DITA compliance. Any tools vendor could claim
DITA compliance without reference to any objective compliance criteria.
- Technical writers outside the DITA community share a perception that DITA is developed by elitists for elitists
- Technical writers outside the DITA community share a perception that adopting DITA is often a precursor to writers and their groups getting outsourced or offshored
- There are few local users groups to support new adopters
- DITA integration with GIT is poorly documented
- DITA provides little direct control over the output formatting of individual pages, e.g.page breaks, table breaks.
- For OASIS to become a true focal point for DITA adoption
- Part of this would be the sharing of open source resources: specialisations, transforms, builds, etc.
- Simplify 'adoption hurdle', especially w.r.t toolkit
Make the toolkit more 'off the shelf' & easily customisable
- Improve the documentation package
- Develop best practice guidelines
- Identify a one-stop DITA solution for small companies
- Build a universal semantic ecosystem
- Encourage tool vendors to improve support
First qualitative, then later quantitative, tool testing & recommendations
- Engage in constructive dialogue with tool vendors
- Fully explain the philosophy and key business benefits of DITA, with cost saving analyses
- Additional cost savings for translation/localisation
- Career opportunities for TAs and others with DITA experience
- Support integration with enterprise CMS solutions
- Build a world-wide market for DITA services and tools
- Simplify DITA (a "getting started" subset)
- Move dita.xml.org to DITA source and DITA based Wiki - how can we claim to promote DITA when we're not using it ourselves!
Minimalist, single source, reusable publishing workflows for unstructured & semi-structured content can include an editor and a CMS and offer a more complete package, e.g. Author-it and others
- Very few legacy content sets support structured documentation - risk of 'pouring old wine into new wine-skins'
- Commercial interests from tool vendors can lead to semi-proprietary solutions and potential vendor lock-in
DITA support from some tools is very poor indeed, even some of the key authoring tools, e.g. FrameMaker
- Tool dependence for the sake of simplifying DITA can lead to vendor lock-in
- Commercial interests from consultants can lead to confusion from plethora of web sites
Other XML-based standards: ODF, Open XML, DocBook, S1000D, ...