• Print

What We Talk About When We Talk About XML (Apologies to Raymond Carver)

Acronyms and initialisms are mysterious and potent, and frequently hide meaning and become shorthand for larger concepts. Just as ONIX became shorthand for “metadata,, XML (at least in book publishing land) is becoming shorthand for … well, a lot of things. Repurposing content, creating templates for book design, tagging — all of these are encompassed in the term “XML workflow.”

So no wonder people get confused. Particularly people who are in the business of creating content, not formatting, categorizing, packaging and marketing it.

So what are we talking about when we’re throwing around this term? It depends on what you do for a living.

If you’re a writer, it might mean using Word a little differently, quite possibly according to specific author guidelines given to you by the publisher. It might also mean including lists of keywords along with your manuscript. It may mean including lists of keywords for each chapter.

If you’re an acquisitions editor, an XML workflow may mean deciding whether you want a book to merely exist as a print product (as a single source of revenue), or whether it’s also appropriate as an ebook, to sell by the chapter (as numerous textbook publishers are doing), to publish iteratively (as O’Reilly does with its Rough Cuts), to make excerpts available for free download, etc.

If you’re a book production editor, an XML workflow will be very concrete — you tag a manuscript according to its format (“chapter heading,” “illustration,” “copyright page”), and those tags are applied to a pre-defined style sheet.

If you’re in marketing, an XML workflow allows you to work with the author’s keywords, target specific audiences for the content, and package the content in appealing ways.

Could you do all of this without XML? Sure. You could use a relational database and shove your manuscript, chapter by chapter, into tables in SQL. You could assign keywords in a relational database. But you couldn’t do formatting. You could use InDesign or Quark to do your formatting. But you couldn’t break up your manuscript into “chunks” and repackage those “chunks” into new products with those programs. XML has the capacity to handle both, and handle them well.

Like most acronyms, XML is a tool. It’s not a goal in itself, but a way to get to your goal.

tags: , , , , ,
  • bowerbird

    > Could you do all of this without XML? Sure.

    thanks.

    > You could use a relational database and
    > shove your manuscript, chapter by chapter,
    > into tables in SQL.

    what means “shove”? it sounds indelicate…

    > But you couldn’t do formatting.

    why not?

    hadrien, over at feedbooks, does it just fine,
    and he uses a database approach…

    > http://toc.oreilly.com/2008/09/qa-with-hadrien-gardeur-co-fou.html

    > XML has the capacity to handle both,
    > and handle them well.

    “has the capacity” is a pretty slippery phrase.

    especially when, over in another thread here,
    commenters are lamenting the absence of tools
    to manage their workflow and output their stuff.

    > http://toc.oreilly.com/2008/09/why-you-should-care-about-xml.html

    -bowerbird