Visualizing the Advantages of StartWithXML

Mike Shatzkin
September 22, 2008 | Permalink | Comments (0) | Listen

Here are two ways to think about why a StartWithXML workflow can be important and valuable:

1. Until very recently, we lived in a world where the book was the sun and everything else orbited around it. Now the CONTENT, the IP, is the sun, and the book is relegated to one of the satellite bodies (still often the biggest, but it is a lot different to be Jupiter than it is to be the sun!) When what is at the "core" is different, the processes to create it have to change.

2. A StartwithXML workflow effectively makes the content file into a database. Just about any information relevant to the book, or any piece of the book, can be associated to the content in an XML file, just as it can in a database. Up until now, this has been seen primarily as a tool for production: the database holding information about document structure that translates into the presentation in each iteration. But the capability applies just as well to rights data, marketing data, or fragment identification.

Can these things be accomplished in other ways? Almost certainly, yes, but XML has the advantage of being an accepted standard, and although it may (will) require some dialog between entities sharing it, using XML is the fastest way to enable machines to talk to machines about anything related to a book's content.

Related:

• See more StartWithXML posts

StartwithXML: Doing a Lot of it Already in Word

Mike Shatzkin
September 19, 2008 | Permalink | Comments (0) | Listen

The question of how much authors can participate in the world of StartwithXML is a matter of legitimate debate. The skepticism about the subject, based on historical evidence, is certainly not unfounded.

But it isn't like publishers aren't already aware that how authors deliver to them matters! Poking around the Web for other reasons, I found instructions to prospective authors on the site of a publisher I didn't previously know, Possibility Press.

As you will see, this publisher instructs anonymous (prospective!) authors about the margins and fonts they should use in Word, and what naming conventions to employ when they save the files (in the specific way that Possibility directs.)

For publishers who have already taken steps like these, the move to StartwithXML will be more like a refinement of current techniques than a wholesale change of procedure. And even if compliance is not 100 percent, and it almost certainly is not, it would seem likely that the work of creating these instructions is saved many times over in reduced work processing the manuscripts at the publisher's end.

Related:

• See more StartWithXML posts

Can the Author Really Help?

Mike Shatzkin
September 15, 2008 | Permalink | Comments (9) | Listen

A very experienced former book packager who has moved on to become an industry observer and critic of some note pushed back on my suggestion on Friday that authors could be involved in tagging content for contextual meaning. "Not in this lifetime," was his comment, and he suggested that copy editors or managing editors might be the more likely candidates to mark what we're looking for.

Among other things, our critic suggests that the usual consequence of having an author mess with the code is that the next job the packager or publisher has to do is pull out a lot of not-useful clutter.

What are we looking for? We want the biographies within a historical book that are used to introduce the characters. We want the place descriptions from any book -- many from novels -- that would be of interest to anybody visiting or looking for information about the place. We want to know which of the woodworking projects in a collection are suitable for Christmas, or require minimal tools, or a minimal skill level, so that we can create different collections for different audiences.

All things like this, the author will know best, usually better than the copy editor. Also better than the acquiring editor. And certainly better than the managing editor.

Extracting the value of the author's knowledge and developing the tool sets and workflows that make it functional to incorporate it in the XML document of a book will require a lot of reinvention. In that sense, "not in this lifetime" is an accurate metaphor for when it will happen. Publishing needs some "born again" changes and this is one of them.

Related:

• See more StartWithXML posts

What Makes IP an "Asset"?

Mike Shatzkin
September 15, 2008 | Permalink | Comments (1) | Listen

For several years in the 1990s, I had the pleasure of working closely with Mark Bide on Vista's "Publishing in the 21st Century" program. Since then, Mark has largely left the book business to attack digital problems of other content industries as well, but I value the opportunity to sit down with him because I always learn something. He was in our office for an hour on Thursday morning and we captured a few gems. Here's one of them directly relevant to StartwithXML.

Mark offered the observation that too many people in publishing don't understand what constitutes an "asset." He maintains that a content asset has two components: the intellectual property itself and the right to use or license it. The content without the rights information is actually a liability, because you'd have to expend effort (which means money) researching the rights situation before you could use or license the intellectual property.

For all the money and effort spent by publishers on DAM systems over the past several years, very few consistently store rights information with the intellectual property. VERY few. One of the things we've learned quickly in the StartwithXML project is that, while an XML repository readily enables storing rights information with the IP, almost nobody uses it that way. One of the leading companies enabling XML workflows actually described our suggestion that the XML document should hold rights information as "a very good idea." It was also, to them, a somewhat novel idea! And they are a cutting edge company on XML workflows.

So chalk up one more reason to go through the pain of the process change to a StartwithXML workflow. If Mark's formulation is right, and I think it is, doing so is the difference between creating assets and creating liabilities with each new piece of IP!

Related:

• See more StartWithXML posts

Beginning the "StartwithXML: Why and How" project

Mike Shatzkin
September 12, 2008 | Permalink | Comments (4) | Listen

Today we start an exciting new industry research and education project: "StartwithXML: Why and How."

No publisher of any size or scope can be beyond the XML conversation that is now taking place across the industry. That content must be kept in a repository of XML files has become common understanding. And all the content-generation tools we use -- Word and InDesign and PDF prominently among them -- enable an XML export, so publishers are finding they can create a post-production XML'd version of their content for their archive.

That alone is necessary, but not by itself sufficient, to achieve even the first goal of making conversion -- to a different book output like large-print or to the Web or to any of many ebook formats -- cheap and easy. You can use Word or PDF to get to XML, but without the discipline of a StartwithXML workflow, you will often -- usually -- get an output that working with XML discipline wouldn't have allowed you to create. If you don't apply the discipline, the XML output doesn't solve your problem. And even if it did, it only scratches the surface of what XML can potentially offer to publishers in getting them closer to new revenues and cutting costs.

The "StartwithXML" project will explore all the issues of moving to a StartwithXML workflow through interviews and case studies with publishers and with the channel partners they will be working with to reach new readers in new ways. We'll be looking at what benefits can come to a publisher today from working this way, and what important steps to the future are enabled for those doing this (and cut off from those who don't.)

I am introducing the project this morning (Friday, 12 September 2008) at the BISG Annual Meeting. That talk covers the who, what, why, when, and how. The discussion will be continuing in this space from now.