Creating DITA with HTML forms
The pattern of "What isn't DITA?"is familiar: if a text object of any kind has a title and optionally some kind of descriptive content, it is transformationally analogous to a simple DITA topic. The observation is important because it opens up a wide range of ways in which initial content for DITA repositories can be created. Today, we'll examine the use of HTML forms for particular recording scenarios
Don Daymigration, editingYou may recall that DITA Open Toolkit provides an Ant parameter for generating titles for tasks:-Dargs.gen.task.lbl=YES . Tasks processed without this parameter enabled normally are rendered without the implicit structure labels. With the parameter, generated titles are inserted as seen in this draft PDF view:
PDF result view of a DITA task with labels generated
The HTML output is similar, which leads to the thought: If the content in that HTML file were textareas or input elements, those labels would be tantamount to field labels in a form for those input fields. How close does this idea come to enabling an editor of sorts for DITA tasks?
A simple, HTML form-based example might have the following required and optional fields, many of which correspond to the generated labels:
Task title: [input field] * Short description: [textarea] Before you begin: [textarea] About this task: [textarea] Procedure: [textarea] * More + Results: [textarea] Example: [textarea] What to do next: [textarea] SUBMIT *=required field
In general, this approach is workable as a server-based approach for encouraging writers to follow a consistent sequence when documenting new procedures. Local JavaScript would enable the "More +" toggle to insert additional step fields as needed.
One downside is the inability to separate <cmd> substructure from other allowed substructure in a step, normally enforced by DITA content model rules in validating editors. Similarly, inline phrase markup has no prompted manner of entry. A writer who knows of available DITA inline markup might know to use literal phrase markup in the field, but other writers might not know that trick. At any rate, literally entered XML markup is always subject to user error such as misspellings or leaving out the / in a closing element.
However, I mention this method because it is definitely on the list of possible ways to collect knowledge in a semi-structured way. By using the contentEditable property for the [textarea] input areas, Rich Text tools can at least bold and italic and list markup easier to insert, approaching the best of all possible worlds short of a more interactive, validating editor.
I will explore one more method, using blogs as overall map-based topic writing platforms, in wrapping up this exploration of very simple ways to encourage DITA content creation outside of mainstream XML editing tools.