My New Pal

During the last year I’ve moved three times at work, and each time I’ve tried to shed some of the sticky detritus of my career in publishing. It’s cube crap, unused in years, but somehow always avoiding the trash bin. Outdated manuals, mystery dongles, piles of spec guide binders, a small moose made of binder clips. Rule of thumb: if you have more loupes than eyes, it’s time to pare down.

The Non-Designer’s Design Checklist

About a dozen years ago, as I embarked upon my journey into the realm of publishing, I bought a book called The Non-Designer’s Design Book by Robin Williams. I’m pretty sure it was recommended to me by the guy who taught my first Quark XPress class. I remember thinking it was a fine and fun book. It may have taught me just enough about design to be dangerous. I made up business cards, and took on a couple freelance jobs designing flyers and the like. Years later I had enough confidence to take a side gig designing newspaper ads. Not exactly the peak of the design profession, but it was fun to at least be the guy picking the fonts. I left that job after I’d made enough to buy a second family car, and then spent the better part of a decade forgetting everything I learned from the Non-Designer’s Design Book. So I was happy to stumble upon a copy of the brand new, 3rd edition a few weeks ago.

The Attack of Captain Buzzkill and the Pancake People

Sounds like the name of a cheesy ’50s horror flick. But actually, it’s my nickname for the book I just finished, The Big Switch by Nick Carr.

I first mentioned him and the book in a post a couple weekends ago. I like my crazy title because Carr documents some futuristic doomsday scenarios that that are actually coming true in the Age of Google.

A Look Under the Hood of the Hybrid

Got such a good response with the hybrid InCopy-XML workflow, I felt like it was worth revisiting to go into some details. Let’s look at the task of creating a new Schema file with XMLSpy.

In The Grand Schema of Things

The whole reason I start with a Schema and not a DTD is that XMLSpy lets you graphically create Schema. It is a heck of a lot easier for a non-programer to do than writing the code from scratch. But I won’t lie to you. You still need to learn something about XML in general and Schema (with a captial “S”) in particular. It’s not quite as easy as just drawing a diagram of your content model.

Well, you can draw pretty much whatever you want, but if you don’t know the pitfalls, you’ll get validation errors. And without a valid Schema, you can’t create a that user-friendly authoring template that you need to sell your editors on this whole XML workflow thing.

Help!

Learning XMLSpy can be frustrating for someone who’s used to working with programs like Word and the Creative Suite. The rules for making valid code are strict, the error messages and other jargon might as well be written in another language. Which, actually it is. And the Help won’t teach you anything about XML you didn’t already know. It barely teaches you about XMLSpy. It assumes you know all the rules for coding, and just tells you which buttons perform which functions.

You could buy a printed copy of the manual on E-Bay for $108 (Altova doesn’t sell ’em). But instead I would recommend you do the tutorial and then keep something like the O’Reilly book XML in a Nutshell within reach at all times, to serve as a de facto manual. That way you can use that $70 for beer and stand just about the same odds of making a useable Schema.

Namespaces

You need to learn about namespaces right off the bat and make them part of your Schema design so you can use InDesign’s feature of mapping XML attributes to paragraph and character styles. This is necessary since not every paragraph is going to look the same in your layout, but they are still all just paragraphs. I’m not going to get deep into namespaces here since I could devote a few posts to nothing but namespace issues I’ve had.

OK, now that I made it sound hard, let’s make it look easy.

Diagramming a Content Model

We’ll create a basic Schema for a Major League Baseball team, in honor of the World Series Champeen Red Sox. In XMLSpy, choose File > New and pick W3C XSD from the list of file formats.

Enter the name of your root element in our case, baseball_team, and an optional description of it.

At any time you can choose Text view to see or edit the code. That’s when you’re really glad you don’t need to ever see or edit the code. It’s like opening up the washing machine while it’s running. You just take a peek, maybe throw a pair of socks in there, and close the lid.

Then click the little blue tree icon to show the Schema diagram. This is where the fun begins.

You now have a wide open field in which to draw out all the children of the root element.

Everything is connected automatically, so you won’t have any loose floating pieces. Now you apply all that stuff you learned in your planning meetings, the elements, the attributes, restrictions and relationships they have. You drag out a connector from the baseball_team element, and choose what kind of child it has.

In this case, it’s a sequence (indicated by the line of dots) of two elements, players and coaching_staff.

players is a sequence of position_players and pitchers. position_players is a sequence of infielders, outfielders, and bench, all with an attribute describing the postion they play. You keep going in this manner till you’ve finished diagramming your content model.

Regarding attributes, if you want to give your editors a pop-up list of values to choose from, enter the legal attribute names in the facets > enumerations tab.

You can also assign minimum and maximum occurrence values to restrict how many of a certain element you’ll allow. In our example, you have to have at least 3 outfielders on your roster to field a team (and pass a validation test). If no number is shown under an element the schema calls for exactly one of that element. Or you can make an element optional by setting the minimum occurrence to zero, like I did with the assistant_manager and the box outline becomes dashed.

Once you are done, you can convert the Schema to a DTD for importing into InDesign, or showing your friends in the bleacher seats.

On second thought, don’t show your DTD in the bleacher seats. That conversation probably won’t end well.

Of course the devil’s in the details, and there are plenty more details, but let’s leave it there for now. That wasn’t too painful, was it? We made the engine of the hybrid InCopy-XML workflow, a real live W3C XML Schema, without hand coding it.

Book Report: The Art & Science of CSS

I was at the library today and snagged another book that I’m excited about: The Art & Science of CSS by an Australian publisher called Sitepoint. It’s written by a team of 5 “visionary” Web designers, one of whom lists mass.gov in her portfolio. It’s definitely not for anyone new to CSS. It assumes you already know all about selectors and properties. By page 12, we’re already into JavaScript for sIFR.

I already have and love Eric Meyer’s Cascading Style Sheets. But this one has the advantages of being somewhat easier to read, newer, bigger (8 x 10) and with color examples. It’s definitely not as thorough as Meyer’s book, which can’t be beat for covering every last detail, as O’Reilly books always do.

But The Art & Science of CSS feels fresh, as does the Sitepoint website. If nothing else, it gives me a break from the look and feel of the O’Reilly and Peachpit (Real World and Visual QuickStart Guides) books, which I’ve been reading for the last 10 years. And thanks to one of the author’s links, I learned my Blogger code:

B1 D+ T- K S+ F+ I O++ X- E L- C– Y1 R- W- P+ M2 N- H

I’ll assign myself the book report on this one and come back here with anything truly shareworthy.

Book Group: The Big Switch

Welcome to the first meeting of the Publicious Book Group. Take a seat anywhere. Coffee’s over there. Our first book is The Big Switch: Rewiring The World, From Edison to Google by Nicholas Carr. I saw it in with the new books at the library, and despite it’s aggressively undesigned cover, checked it out.

I’ll read it over the next couple weeks, and post my thoughts back here. If anyone wants to join in and read along, or if you’ve already read The Big Switch, please comment and make this a conversation.

The Book

The book is about about the impending death of desktop computing, and the takeover of web apps. Seems quite relevant to publishing industry and the tools I talk about here. Just look at Photoshop Express, moving a big complicated app and the files it processes from a desktop machine to a hosted “data cloud.” Sure Px is to Photoshop CS3 as Fruity Pebbles is to the Honeymooners. (Stay with me, there.)

If Carr is right, some day in the not too distant future there won’t be a desktop version of Photoshop. We’ll have to subscribe to some level of Adobe Creative Suite Service to use it. I can see it now. “You have 500 Nationwide Photoshop Minutes Remaining on your account. To add minutes or brushes to your palette, press 1. To speak with a Prepress Expert, press 2…”

On the plus side, I imagine the History palette will include every keystroke I ever made. On the downside, I’ll probably only be able to afford the Cheap Bastard tier of services, and the “Blade Runner Enhance” filter will be grayed out.

The Big Switch also seems relevant to me personally, since at work I’ve just witnessed a transition where many skilled people and the machines they used left the building. That move would not have been possible before a Web-based workflow. And I get the sense that more and more of the apps I use at work will soon float off into the cloud. Maybe I will too.

The Author

I am arriving late to the Nicholas Carr party, just as I was late to the blogging party, but I think there’s still some Doritos left in the bowl. The man that Wired describes as “high tech’s Captain Buzzkill” set off a literary bomb in tech circles 4 years ago with the publication of Does IT Matter? Information Technology and the Corrosion of Competitive Advantage. Google Books has about 30 pages that you can peruse.

Guess he felt like the original title, IT Doesn’t Matter gave away the ending.
The basic premise was that IT’s importance is dwindling, since 1) everyone has it, and 2) it’s become so standardized, it’s a commodity, like water or electricity. You need IT to do business, but spending more won’t give you an edge over your competitors. And the best strategy is to be on the trailing, not leading edge of innovation.

With Chapter titles like “Vanishing Advantage”, and “Managing the Money Pit”, he wasn’t exactly cheering on the geeks. Needless to say, this ruffled the feathers of some rather large birds. The book managed to piss off Microsoft, HP, IBM, Intel, and every guy who ever plugged in an Ethernet cable at work. Entire conferences were devoted to de-bunking the book. So I guess the catering industry likes Carr.

Further Reading

Nick Carr’s blog

His regular old-fashioned website complete with drop-shadowed torn paper banner

And the inevitable, Does Nick Carr Matter?

Sometime when you’re you’re feeling especially meta, check out the Wikipedia article on Carr, which attempts to describe Carr’s description of itself and the rest of Web 2.0. Holy circularity Batman! I’m blogging about a Wikipedia entry about an author writing about blogging. It’s starting to feel like the scene in Being John Malkovitch, where Malokvitch takes a ride into his own head and everyone’s a Malkovitch Malkovitch Malkovitch.

Malkovitch!

Family Cookbook 2.0 continued

When we left off with our project, we had transmogrified the cookbook Quark file into InDesign, and a made few observations about the potential work needed to make it the apple of our cross-media eyes.

Remember, what we (I) have to work with is Quark Xpress 4.11, InDesign CS3, Acrobat, and no scripting knowledge, Xtensions, Xcetera. At the finish we want to serve up our cookbook content in an nice HTML/CSS website, plus a new InDesign doc for print.

Before we start working in InDesign, just so you’ll never think I’m lazy (crazy, sure; lazy, no) here’s a list of alternate methods I explored for getting the content out of that old XPress file, and why I didn’t choose them.

The Roads Not Taken

1. Quark to ASCII: yields nice clean text, but no hooks to attach the XML tags to, and the text from the recipe cards gets left out since it’s not part of the main story.

2. Quark to XPress Tags: a little more interesting. Any time we hear the word “tags” our ears should prick up. It also gave me a reason to dust off David Blatner’s venerable Quark XPress 4 Book, and read the section on XPress Tags. His enthusiasm about them makes me feel like I missed out on something cool, well geek cool, since I never really used them before. Guess I’ll never know.

Quark’s tagging syntax is quite different from XML. It’s based on presentation and uses only opening tags. So we’d need to be clever about crafting a Find-and-Replace scheme. Before I read A Designer’s Guide to InDesign and XML, I would have just given up and moved on, but that book gave me the confidence to try just about anything with Find and Replace. I’ll spare you the gory details, but in 3 steps, I went from the XPress Tags and whitespace surrounding the ingredients to real live opening and closing XML tags.

So this method does work. But it kind of hurts my brain. And anyway, there’s that same deal killer of the recipe card content getting left out. Ahh, if only I could go back in time and warn myself not to put that stuff in inline text boxes…

3. Quark to Word: I can save to either Word 6 or Word 8. Both versions crash InDesign when I try to place them. No thanks.

4. Quark to PDF to Word: practically every paragraph is in it’s own text frame and somehow my 6 paragraph styles have ballooned into 44 styles named CM1-CM44. Pass.

5. Quark to PDF to RTF: I had high hopes for this one, since I thought it would reuinte those inline boxes with the rest of the text and have a style attached to everything. But I’ve tried several times to import it into ID and it crashes it every time. Sucks to be me.

6. Quark to PDF to HTML: no cards, plus everything’s chopped to bits in tiny <p> and <span> elements that don’t really correspond to meaningful elements. I think I need a beer.

7. Quark to PDF to XML: This is also kind of interesting, but not in a good way. More like Marshmallow-Peeps-in-a-microwave interesting. Almost everything is wrapped in <P> tags, which alone would be a deal breaker. But I really screwed things up by carelessly making the PDF from Quark with missing fonts, and as a result some of the recipe cards have overset text. Of course, the PDF doesn’t include any of that overset text, so it’s just gone. I also think the missing fonts resulted in some of the ingredients ending up in table tags. Very loose lines of justified text also got put into tables. “Clean-up in aisle 7!”

8. Quark to PDF to Mars to SVG to XML: OK, I need to stop. You get the point. Besides if I do the work in InDesign, I can make use of what’s already there for the print side of things.

If you just can’t get enough of this text-out-of-Quark topic, by all means check out the InDesign Secrets thread on it. It just makes me jealous that I don’t have access to things like TeXTractor (or a comp vendor in India).

Here’s how you know you’ve drunk the Adobe kool aid: I can’t type the word “India” without capitalizing the “d,” so it’s always InDia the first time. I am no longer capable of InDependent thought. InDeed, it’s InDefensible.

InDesign clean-up

Ahhh, it feels so good to be back in InDesign after all that Quark-Word silliness (told ya I drank the Kool-Aid). Let’s do this quick. I want that text creamed and buffed with a fine chamois, and I want it now. Chop chop. The first thing is to clean up the paragraph styles so they match the element names I want to use in my XML. I have the luxury of not having to conform to a DTD or Schema, so I can call ’em anything I want. For now I’ll stay with simple semantic names. Then I’ll create tags with matching names that match the styles, and I change the default Root to cookbook. I’ll tag the story frame as recipies.

Now to clean up those two-column ingredients. A quick trip to the Find/Change dialog will suffice. First we replace all tabs in the ingredient style with paragraph returns. I also had some soft returns in there to put comments under ingredients, so let’s replace those with regular spaces. And last let’s use 3 of InDesign’s built-in GREP searches to tidy up any extra returns, spaces, or tabs.

Now comes the moment of truth. Mapping Styles to Tags. If I’ve done things right to this point, everything will fall into place. And…I think it worked. The XML is pretty flat but I like what we’ve got here. In a project with more than one destination for this code, I’d want some nesting so that each recipe was a enclosed in a set of tags, and maybe even the ingredients and groups as well. But this is a one-off kind of thing.

The next step is straight out of A Designer’s Guide… Chapter 9 to be precise. Since there’s no other re-use of this content besides a page on a Web server, then there is no need to get all huffy about keeping the semantic nature of our tags. I already have things grouped consistently, so I can change XML tags to HTML tags, add a few things and I’m good to go. First I’ll change cookbook to HTML, then add a tag called head, and drag it waaaaaaaaaay up in the structure pane, just under HTML. I’ll change the recipes tag to div, and map the card tag to it. The code is starting to look Webbish.

Let’s export it.

InDesign gives me a little agita on the way out:

I tried in vain to find these shady characters. How dare they refused to be encoded! I want to speak to their parent elements!

I thought the warning might have something to do with the Structure Pane Gremlin I’ve seen from time to time. Here he is.

Has anyone else seen this thing and know what it is? Looks like an Asian character of some sort. He is darn difficult to get rid of. I’ve had to untag and delete all the surrounding content to get rid of him. I thought maybe the Department of Homeland Security had bugged my InDesign file to see if I was a terrorist. Or maybe it’s just a glitch in the Matrix. Nothing to worry about. The Gremlin appeared 3 times in the cookbook code. Unfortuantely, even after removing all 3, I still get the warning message, so I have two unsolved mysteries. But the good news is the code looks fine when I eyeball it in Firefox.

That’s all for now. When we pick this up again, we’ll try to achieve Find and Replace nirvana in oXygen and test my ability to use CSS without making a MESS.

Family Cookbook 2.0

Now that all our Easter eggs have been consumed, let’s continue on with that XML theme with a little project to illustrate the joy and pain of bringing old content into the brave new world of cross-media publishing. The goal is to take the files from old print project, languishing on some dusty CD in the basement, and give them new life as spiffy Web content.

The content we’re going to work with is a cookbook. And yes, I did hear that collective groan from across cyberspace. If you’ve read anything about XML and publishing, you know that all XML demos are based on cookbooks. I think it’s a law or something. Actually, I really did want to update the cookbook and put it online, so I grabbed it for this demo.

I’ll break the demo up over a few posts since it’s too much to digest in one sitting. It hurt to write that one, but I couldn’t help myself.

The cookbook was a personal project. I made it when my son Ethan was a baby, to say thanks for all the help everyone gave my wife and I at the time. I was also inspired by the memory of a great-grandmother, Nana Mac, a legendary cook who never wrote down any of her recipes.

Now they’re all gone with her. I wished that my kids could be connected in a some way, to the great people who came before them. So I sent out a request to all family members to submit their favorite recipes and any interesting stories that went along with them. I got a nice response, 54 recipes from 28 people.

I transferred all the recipes from hand-written index cards, or copied and pasted from e-mails into a Quark layout. Like my fellow Southeastern MA native, Emeril Lagasse, I kicked it up several notches. I probably went overboard, with not one but two indices, a forward and a dedication, and of course drop shadows on every page “burned” with ShadowCaster. I figured out the imposition and printed 30 copies of the pages on my Epson Stylus Color 740i, which matched my Bondi Blue iMac. The Epson still cranks out pages today. Never fed it an OEM ink cart either. The inkjet gods must be smiling on me. I bound the books, using a cordless drill and hand-bent staples. Ouch! Talk about old world craftsmanship! Could have used one of these sweet book staplers. Then again, maybe I should’ve just gone to Kinko’s. But the whole point was to do it all myself on the cheap. The book came out quite nicely, if you forgive the slight shingle of the pages, and the fact that I didn’t laminate the covers, so they get a bit smudgy in the kitchen.

I undertook this project in the spring of 2000. Those were the days when the wooly mammoth known as Quark XPress 4, roamed the Earth and dominated the publishing world with a 90% market share. Yes, there was a new thing called InDesign, but I laughed at it. Version 1.0 would launch, sort of. Everything else I tried to do with it caused it to crash. I mocked it as Illustrator with multiple pages. When InDesign 2.0 came out I quickly changed my tune. But that’s a story for different day.

Thus for our current project we have the dusty old Quark 4.04 file and a couple of pieces of art. Nowadays, I pretty much bleed Adobe Red (Pantone 485). I don’t own or know the versions of Quark XPress after 4.11. This is a problem for a few reasons, not the least of which is, if I upgrade all my machines to Leopard, I’ll be without Classic support, and thus without Quark. There is a workaround: have a partition running Tiger/Classic, but that’s like having to keep a second stereo in the living room to play your 8-track tape collection. Perhaps it’s time to upgrade. I must at least check out, if not actually buy XPress 7. I’m looking forward to it, but with the same feeling when you meet up with an old friend you haven’t seen in years: a mix of curiosity and unease. What’s changed? Will we still get along? Does he still remember the secret handshake (keyboard shortcut)? For now, we’ll attempt the Extreme Cookbook Makeover with InDesign CS3, Syncro Soft’s Oxygen, and Dreamweaver.

One last a stupid question: Why is it when I type “Dreamweaver”, I hear the song from ’70s? “Ooohh, dreeeeem weavahhh, I believe we can reach the morning liiight.” Maybe it was Wayne’s World that resurrected those dying neurons. But I am suspicious there’s also a K-Tel Records commercial playing endlessly in some dark corner of my mind. That would explain a lot. Hopefully my curse will not now become yours. OK, this blog is over 3000 words old, let’s finally do stuff.

CookBook Makeover

Step 1: The Conversion Drop Ye Olde XPresse File onto InDesign CS3. On my vintage G4, 40 seconds goes by before the Open progress bar appears. Tempting to go play on the Web, but in the interest of science I will ignore my ADD instincts and wait it out. For about a minute we get the “Converting Regular Spreads” message. Hmmm. What exactly is a “Regular” spread? Does this mean there are “Irregular” spreads? “Atypical” spreads? “Highly Unusual” spreads? I’d hate to have InDesign tell me it was converting “Unprecedented” spreads. Then again, that seems a little exciting. I have seen this dialog box a hundred times, without ever really comprehending it. Do I care enough to Google? Apparently so, and here’s the answer: “Regular” spreads are document pages, the ones that actually get printed in the book, as opposed to “Master” spreads which hold master pages. Hoping for something more interesting weren’t you? So was I, but we move on.

Next up, Warnings. “Shadow attribute not supported for characters.” OK, I don’t remember ever shadowing characters, but I’ll take your word for it, InDesign. Go on. “Missing Fonts.” No surprise here. Almost all the files I ever open were created at another time in another place, so this is my default state of existence. I was born missing fonts, man. I could load the entire Adobe Font Folio, add everything from Linotype, ITC, and ImageClub and somehow I’d still be missing FranklinGothicDemiCaramelMacciato.

What I really need is a preference like this:

Alas there’s not, so we dismiss, and we’re in. Let’s take a look around.

All the recipes have the title and chef in inline text frames, like they did in the XPress file. To InDesign, that content is out of the flow of the story. So merging content is one hurdle to clear before we export the XML. Everything seems styled; that’s good. Thanks, Y2K self. Hmmm, the ingredients are in 2 columns. That might need to be cleaned up before I apply tags. There are a few scraps of whitespace trash lurking here and there, but I think we can make a go of it.

Since we’re starting with a converted XPress file, I am reminded of a neat InDesign feature which may be of some use to people. Normally if you choose InDesign > About InDesign… you get the lovely InDesign Purple (DIC 2618 or 40c100m) Credits window, with the version number. But if you add the Command key, you get an info-packed window called Adobe InDesign Component Information.

All the supertechy details of your document’s existence are laid bare, including whether or not it was converted from Quark XPress or PageMaker, all the versions of InDesign (including the build number) that touched the file, whether it is crash-recovered, opened with missing plug-ins, etc. It’s like doing a DNA test on your InDesign file. This info has helped me in the past with troubleshooting, in terms of hunting down what was causing a file to crash, and where in fact a file came from.

Note that like in the screen grab, Write Log File is grayed out until you save the document. If open this window with no document open, it still works, you just get the top of the dialog filled out with info about InDesign’s state for troubleshooting application problems instead of document problems.

OK, that’s all for now. Next time we’ll do text clean-up and tagging.

XML is like…Cousin Oliver

Today’s topic is everyone’s favorite publishing tech du jour, XML. I am not a true XML geek by nature. I don’t know much about its uses in programming, data interchange, etc. I look somewhat dumbfounded at the XML vs. JSON flamewars. Coding is not fun for me. It’s a chore, less odious than cleaning out a cat’s litterbox, but more tedious than emptying the dishwasher. I think of it like changing the oil in the car–you can save a few bucks doing it yourself, but if you do it wrong, things will get messy in a hurry. I try not to fall in love with any software, process, or technology. They’re all just means to an end. Tool-based thinking gives me the creeps. It’s the medically-proven first step to becoming a zombie. I am just interested in XML for the solutions it offers publishers. So even though I went to the XML Conference last December and enjoyed it, I was probably the least XMLish person there.

So along with that disclaimer, if you want truly informed XML talk and tools, check out these:

If you’re barely sure what XML stands for, start with the W3 Schools’ XML tutorial

Then if you’re still interested, check out some of these:

xmlaficionado

Cafe con leche

IBM’s developerworks

XMLScoop

XMLPitstop

XML is a lot of things to a lot of people. For fun, Google the phrase, “XML is like” Here’s a sampling of the results you’ll get:

“XML is like a drug: when you think it’s solved all your problems, you’re using it too much.”

“XML is like HTML with the training wheels off.”

“XML is like sex, even when it’s bad it’s still pretty good.”

“XML is like cardboard. It is a very useful packing material…”

“XML is like lye. It is very useful, but humans shouldn’t touch it.”

“XML is like a fat tick after a good meal…bloated.”

“XML is like a set of Russian dolls where text can be nested at each level.”

“XML is like teenage sex. Everybody talks about it, and thinks everybody else is doing it, when they’re really not.”

“XML is like a carcinogen. We don’t notice it’s there, but we’re still getting exposed to it.”

And probably the most famous and oft-repeated:

“XML is like violence: if it doesn’t solve your problem, you aren’t using enough of it.”

Now, how could you NOT be fascinated with something that is simultaneously compared to sex, drugs, violence…and cardboard?

To me, it seems like XML is to the ’00s as PDF was to the ’90s: a technology that eventually all publishers will be using. Both are charmingly flawed, but will end up being adopted anyway. So XML is like Cousin Oliver in the Brady Bunch.

XML and PDF. One’s about structure, semantics, and meaning while the other’s about portability, predictability, and drop shadows. Adobe’s working on an interesting mash-up of the two, called Mars. Think of it as a digital Reese’s, with PDF as chocolate, and XML as peanut butter. I’ll do a proper post on Mars in the near future.

As was the case with PDF, I think XML’s invasion of publishing tech is inevitable. There are just too many benefits, for us not to end up tagging everything. Someday we’ll shake our heads in disbelief that we ever worked with un-tagged content. So primitive. Is XML the perfect means for tagging content? No, it can be clumsy and verbose (but so can I). It might be fair to paraphrase Churchill, and say that XML is the worst tagging system, “except for all the others that have been tried from time to time.” We just need the other pieces of our publishing systems to evolve so we can reap the benefits of all those tags, while keeping the XML mostly invisible. Or, to risk infamy and quote Churchill twice in one paragraph, “Give us the tools and we will finish the job.” Of course, he was talking about things that explode.

Since I’m in a quoting mood, I am reminded of a conversation I had last year at the InDesign Conference. I took an XML class and the instructor made a good point when I told him I was struggling to learn XSLT. He said, “You make PDFs all the time, but not by hand coding, right? So why would you want to hand code XSL?” He wasn’t trying to discourage me from learning, but rather to realize that there are and will be more powerful tools to make a publishing XML workflow really fly. Specifically, he showed me MapForce by Altova to graphically create XSLT. Hand coding is a great and essential skill for some, but the easier it is to use any technology the faster it can really take off.

With the release of Creative Suite 3, InDesign took some significant steps forward with support for XSLT, XML rules, Text Variables, and other new features. Those of us who have been exploring the use of XML in InDesign, got a nice Christmas gift last December, with the publication of A Designer’s Guide to Adobe InDesign and XML by James J. Maivald and Cathy Palmer. If you want to understand the sometimes strange relationship between XML and InDesign, get your hands on this book. Or at least head over to the authors’ site, cookingwithxml.com. Adobe’s official documentation makes a nice side dish, especially the technical reference found here. But Maivald’s book is the main course. It is by far the most comprehensive and well-written instruction on this topic I’ve seen. I love the tone of the writing, which is friendly and informal, but not too silly (something I strive for myself). The authors know that when it comes to XML in InDesign, there’s a thin line between elegant beauty, and unfixable junk. Sometimes, the difference a single keystroke.

I’ll probably also buy Simon St. Laurent’s XML, Meet InDesign from O’Reilly soon, because a) I like the title, and b) I like the author’s hat.

If you are new to InDesign and/or XML, and do decide to use the Maivald book, here’s a tip: read every word. I’m not kidding. Every word of every sentence, in order. And pay attention. Have bright lights on in the room. And that Handel concerto playing softly in the background. And it helps to be slightly caffeinenated. Seriously, if you are new to this, do not skip around. There can’t be any gaps in your understanding or execution of XML in InDesign, or it just won’t work. Believe me, I’ve been tinkering with this since InDesign 2.0. I’ve made every mistake there is. Several times.

Given all that, is fragility of an InDesign XML-based layout a deal breaker? If it’s that hard to get right, and that easy to break, what good is it? How can it work without automated workflows and/or an army of scripters? Is there really room for human hands in an XML workflow? Good question. I think it points to the fact that right now highly-designed, “hand crafted” layouts and XML are an uneasy marriage. Think Arthur Miller-Marilyn Monroe. Or maybe Stephen Hawking-Paris Hilton.

But in 10 years, whether we’re using InDesign or something else, I think all the coding will be hidden under a GUI coating and we’ll have self-healing layouts that are impervious to the whims of designers and editors. Kids will be making XSLT by dragging their creations around onscreen and molding them like digital Play-Doh. And they won’t have a clue what XSLT stands for, nor should they. For the grown-ups maybe it will be something more like TurboTax, where the software interviews you, asking what you want to do with your content, and all the calculations are handled in the background. Let’s just hope the IRS doesn’t introduce a tax on tags any time soon. Actually, maybe a tag tax would help pay for things in Iraq.

Next time, I’ll share a little project of mine, taking old content and making it new again via XML.And as promised, here are a few tidbits so you don’t go hungry:

1. For anyone interested in a behind-the-scenes look into the world of educational publishing, check out the The Muddle Machine: Confessions of a Textbook Editor by Tamim Ansary. It’s more than 3 years old, but still a fantastic read. And the accompanying graphic alone is worth the trip. It also reinforces my Six Degrees of Star Wars theory, as edutopia.org is a project of the George Lucas Educational Foundation.

2. Again with the educational angle, here’s Bill Gates proclaming textbooks are dead. He’s right, or at least he would be if we could all afford the hardware. At my kids schools, we get hit with fundraisers and teacher requests for classroom supplies from the first day. My son is using a spelling book from 1994. I don’t think a tablet PC will be coming his way any time soon. I’m sure Bill’s used to a slightly different set of circumstances.

3. Here’s one for the true prepress geeks. A challenge by the Sandee Cohen, for someone to demonstrate why in this day and age you would ever want to use a Photoshop EPS file in lieu of PSD, TIFF, etc. I love questions like this that make us prove ourselves and debunk the myths.

4. Lastly, here is a guy who really, really likes bookmaps.