Earlier in the series:
Theoretically, DITA is not necessarily required to implement the features described in the earlier posts of the series. A proprietary technology can be developed and used to achieve the same goals. The problem with a proprietary technology, though, is in high costs of building it from scratch. You can buy a ready out-of-the-box product based on a proprietary technology, but this will make you totally dependent on the product’s vendor.
So here comes Reason #7:
Reason #7: DITA Is an Open Standard
Using DITA to build a solution for documenting requirements and automating document assembly lets you enjoy a lot of benefits:
- No need to waste time for creating a proprietary standard from scratch. Creating a standard for structured content requires a lot of efforts: developing DTDs or schemas, configuring generic XML editors and other tools, developing publishing stylesheets from scratch, and so on. DITA gives you an infrastructure for both creating and publishing content out-of-the-box so you don’t have to reinvent the wheel. Plus maintaining a proprietary standard along with the tools that support such a standard usually involves pretty high costs and risks.
- The DITA’s standard semantic markup can be adjusted to your specific needs. DITA provides a special mechanism, called specialization that allows you to flexibly create your own content model and elements. For example, if you want to make the markup for requirements for intuitive and enforce more restrictions, you can create a new information type that will require having a mandatory <requirement-definition> element followed by a mandatory <related-requirements>.
- DITA is being constantly developed and becomes attractive for non-technical users. The first version of DITA was officially released in 2005, and since then has evolved dramatically. While the first early adopters were primarily software companies that used DITA for user manuals, in our days, DITA is being used far beyond technical publication departments. Thanks to authoring tools that entered the market in the last few years, DITA becomes usable for many content creators who have no idea (and don’t have to) about XML.
- DITA is supported by a wide variety of tools. With DITA, you are not locked-in to a specific tool or vendor. As an open standard, DITA lets you build a solution that involves different tools from different vendors still using the common and transparent information infrastructure. This is especially important when content contributors with different technical knowledge work on requirements. Technical writers can use a professional DITA editor, while business analysts and product managers can be provided with a WYSIWYG online editor that hides the DITA’s complexity and offers them an MS Word-like experience. Because all these tools support DITA, all the groups of content contributors can now enjoy rich reuse and automation capabilities that DITA offers and collaborate.
- Solutions are scalable. For example, we’ve built the early version of the requirements documents generation tool just with a standard DITA, standard DITA Open Toolkit, and some XSL coding. After we’ve seen that the tool is working and provides value, we can now make the next step and specialize DITA (again, using standard mechanisms) to create a more intuitive semantic markup specifically for requirements, plug in a third-party WYSIWYG online editor to let business analysts who don’t know DITA contribute, and so on.
- The evolution of DITA doesn’t depend on a specific vendor. DITA is a community work. A lot of companies and individuals are involved in the development process that started in early 2000’s and never stopped since then.
- There is a community of DITA practitioners. The DITA community is constantly growing and offering new initiatives that improve DITA and expand areas where it could be adopted. There are also a lot of DITA users who share their experience with you and from whom you can learn. Choosing DITA, you choose a collective knowledge of thousands of DITA users.