Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Clone this wiki locally
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)
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.
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.
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
- Tools (authoring and processing)
- The schema(s).
- 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