When a DITA information set is transformed into a book, the deliverable is a self-contained. Its navigation devices (page numbers, TOC, index, cross-references) are constructed from the DITA source. Likewise, when a compiled Help deliverable is created, the navigation is constructed. However, a compiled Help file is typically read in a viewing program that allows full text searching; that form of navigation is provided by the viewing engine, and is not derived from the DITA source.

But what about when uncompiled Help, such as a bunch of HTML topics, is generated from the information set? Yes, the "derived" navigation (TOC, maybe an index) might be created, but where's the full-text search? The viewing engine (a browser) only has the abiltiy to search within the current topic, and is blissfully unaware that a topic is part of a collection to topics.

Most HTML-based Help authoring tools (HATs) create a "WebHelp" output which includes JavaScript search routines that permit text searches through the collection of topics. And if HTML output is to be hosted on a Web server, a server-based search engine could be configured to permit searching through all topics.

Is the lack of a JavaScript search facility in DITA OT generated HTML output from DITA going to throttle DITA take-up? Will the benefits of a DITA authoring approach be overshadowed by the obvious inferiority of DITA-generated HTML compared to HAT-generated HTML?