Each team approaches joint projects in a unique way, depending on the chemistry between the authors and the strengths each brings to the project. One person might be in charge of one theme which runs through the book while the others act a accessories, each contributing minor excerpts to support the main thread. Or the group might become decentralized where every author writes a chapter or section of the book independent of the other parts. Sometimes there are researchers and writers. The researcher finds all the supporting evidence and the writer mashes it, stirs it, and produces a cohesive final book.

Today there are books being written by many people, 144 characters at a time, on Twitter. Brandon Mendelson wrote The Falcon Can Hear the Falconer in Twitter. Instantaneous writing and reading. Ever sit on pins an needles waiting for the next installment of a sequel? Imagine the story is unfolding, tweeting out to your desktop, as your working. And these Twitter novels don’t have a plan, an outline, to speak of. How could thousands of people write to an outline, instantly, in 144 characters? The content reflects real time, it’s certainly not static. Current events make their way into the story as the event occurs. The downside to this is managing the contributors, writing time, and the danger of loosing the main theme.

Collaboration takes another twist in an Agile environment. For those of you who don’t know Agile development, on one foot, it is development to small goals within a limited time frame, usually a week to three weeks long. Certain small goals are set and worked towards. Then the project is reanalyzed and new goals set for the next round or sprint. Writers have to adapt to a new writing cycle between themselves and among the Agile team. Publishing collaborative works follows the general model, if you don’t look too closely. The introduction of writing sprints changes everything. Publication dates become part of a sprint. The piece might be “published” many times before it reached its intended audience.

The next model is slightly more complicated. I’ll be looking a single sourcing information and its relevance to commercial publishing.

First, DocBook is not a definition of how the book looks; it is a definition of the structure of the book. Instead of saying that a paragraph is displayed with Times New Roman type at 12 points, with 6 points before, DocBook marks the text as a paragraph. Later a style sheet can be applied to the document which says that any paragraph is represented by Times New Roman, 12 point type, with 6 points before. This is not so important if the book is only published in one format, ever. But, if the book is published in different formats, for example, as a printed book and as a eBook, the same DocBook file, with two different style sheets, can perform the two different tasks. This is a tremendous savings.

I know I’m coming at this from a technical writer’s point of view. Using something akin to programming is not scary in the technical writing world. For traditional publishers this might be a little daunting at first. The payoff, however, is tremendous.

I heard a great Tools of Change panel discussion (2009) with members from Blurb, Greenleaf Book Group, Thomas Nelson, Lulu.com, and O’Reilly Media about the future of publishing. Phrases like, “nothing but NET”, and “we’re on the cusp”, [we have to] “get it out to the world” point to a revolution in publishing. It doesn’t take much to note the number of publishing houses that are folding or are undergoing immense transformations to stay in business. The publishing industry is no longer about books. It is about information.

DocBook is one example of how information can be stored, retrieved, and disseminated to the public. It has the advantage of being Open Source. Open Source is self-regulating and constantly moving forward to meet the needs of its community. DocBook is well-established. It has almost 20 years of experience under its belt. And because it has so much history, it is comprehensive.

Are the drawbacks? Yes. Using DocBooks is not “what-you-see-is-what-you-get” (WYSIWYG). For an author that is a daunting prospect. To take an author’s manuscript and port it into DocBooks does take time; it is not instantaneous. Designers, book layout artists, anyone involved in traditional book publishing may have difficulty at first adjusting to tags, elements, and style sheets.

Are there any WYSIWYG front-ends to DocBooks? Yes. oXygen is one. As time goes on more will emerge.

In the beginning Big Blue (IBM) developed a language, GML, that allowed expression of abstract syntaxes that could later be expressed as a concrete syntax in a specific instance or environment. This meant that I could store a paragraph or sentence or even a word and associate it with a label (tag). Later I defined the tag to display in a 12pt Times New-Roman font, indented 1/2 and inch, with 6 pts of spacing between units. I could also define that tag to display as Courier 48 no spacing in another document. The tags gave me the flexibility to change the way the item looked without changing the item itself, abstract vs concrete.

In October of 1986 ISO adopted SGML, Standard Generalized Markup Language. It went through two major updates, in 1996 and in 1998, to arrive in its current form. The 1996 update extended the naming rules and the 1998 update supported XML and provided better support for the World Wide Web.

Enter HTML. Way back in 1980 Tim Berners-Lee started down the HTML path. By 1989 Berners-Lee and Robert Cailliau each proposed an internet-based hypertext language, which led to collaboration on the W3 hypertext project. By 1991 HTML was public. Although Berners-Lee considered HTML to be an application of SGML, it really wasn’t; it developed its own identity. HTML is know best for web page creation.

XML appears on the scene in 1998, when SGML was updated to include XML. XML is true subset of SGML, and it is extensible as it allows users to define new elements. While XML can be used to create web pages, it combines many standards result in separating the information from the display of the information. The syntax is not platform dependent, making reusability and portability one of its key features.

XHTML, eXtensible Hypertext Markup Language appeared on stage in 2001. This reformulation of HTML conforms to XML good document practices (we’ll talk about what makes a good document at a different time).

Yes, there are many other formats and languages floating around. If you understand the major concepts of SGML, XML, HTML, and XHTML, you have a basis for understanding the tools being developed using these languages. The vocabulary eventually falls into place. And unless you have to start programming in any of these languages, all you really need next is to understand the major document components for each language (they are very similar) and to understand that by separating the content of the document from the look-and-feel of the document opens you to many publishing forms while reusing the original content.