Skip to content


Thomas Schraitle edited this page Nov 1, 2018 · 2 revisions

A Docbook Workshop

Developed after a request on docbook apps mailing list 10 Feb 09

Ideas for the scope

  • Develop ideas on a wiki (Docbook wiki?)
  • Need to clarify the objectives.
  • Bob - training docbook developers
  • Michael - tools and error messages
  • ? - A general intro to docbook.
  • Why docbook (Business justification and technical considerations)
  • Others?

The 'why docbook' would make a good session. I'm sure the team have material on that. Two views there. Why docbook for beancounters, and why docbook for markup geeks, which should be two way.


Either a general audience, or an audience from a specific organization, such that the workshop could be tailored to that organizations needs, e.g. use of a specific editor, output media

If we have an objective for one or more workshops an objective can be developed, then a timetable and duration.


What do we expect in terms of experience from attendees? Could be anything from zero XML experience through to some XML, XSLT, DTD | rng experience? If that is the spectrum then I'd propose that some experience is required of XML, XSLT, Schemas. Without that a basic XML course would be appropriate.

Candidate sessions

Suggestions only.

Docbook, What is it, why it is successful, use cases, suitability

Designed for technical documentation. Content kept separate from format. Open to computer processing. Choose your publishing tools. Cross platform. Automate your processing of the XML.

Why docbook - technical and business reasons

  • We can prepare for more delivery formats.
  • Technical input needed [Tool selection, workflow integration, presentation].
  • XML learning curve.

Docbook is best suited for

Multiple output formats. Multiple releases over time (versioned documents). Large documentation sets easily integrated. Batch processing environment [cf hand finished items]. Shared authoring, merged as part of a workflow.

Workflow considerations

How well does XML fit with your current workflow? Cost of process changes? Which people / groups will a change disrupt? How can that disruption be minimised, prepared for? Consider upstream and downstream

Starting out with Docbook

We need.

  1. Tools (authoring and processing)
  2. The schema(s).
  3. The Docbook documentation

Outside advice or internal assistance. Optional, but cost effective.

Willing to help? Have material to offer?

Use the docbook-apps mailing list if you can't get wiki access. DaveP

Clone this wiki locally