A Little Snag


We’re in the process of building a new XML publishing system. It’s going to be swell. But it doesn’t exist yet. We have an “old” XML publishing system that’s kind of languishing right now. No new projects are going into it. Lots of the people who used to work with it are either reassigned or no longer with the company. And there are over 100,000 pages of stuff in it.

Occasionally, one of the books that was created in the old system comes up for reprint. We like to take those opportunities to make corrections. Well, what do you do when most of the people who used to do this kind of work are gone? And on top of that, what do you do when the reprint work is assigned to a vendor who doesn’t have access to your system?

You panic. You hurl accusations. You scream about lack of planning. Then you relax and try to figure out what to do.

In our old system, each book exists as a set of XML files and a high-res PDF that was sent to the printer for the original run. If the corrections are light, then it’s possible to make them in the PDF files themselves, avoiding the whole XML thing. That at least gets the corrected book printed. I suppose it would be nice to make the same corrections in the XML files as well so our content is synchronized. But if we have the ability to do that, then why not just fix the XML and make a new PDF? The problem right now is nobody is available to fix the XML. So we’re essentially going to have bad XML, and if we ever want to move it into the new publishing system, somebody is going to have to remember that it needs to be fixed first. What could possibly go wrong?

Another idea would be to give the vendor access to the old system. But that’s fraught with peril as well. Technical and security issues aside, what’s the point in training a vendor to use a system that you’re planning on discontinuing? And what if there’s more than one vendor that we’re planning on using for this kind of work?

We could also give the XML to the vendor and have them figure out how to make pages with it. That’s kind of the beauty of having vendors: you can tell them all kinds of crazy things and it’s their job to figure out how to make them work. But imagine the time and expense they’d have to put in to make it work. We’d essentially be asking them to replicate our system in their shop. That ain’t right.

So what’s the solution? Seriously, what is it? Because I have no idea. Anyone?

Advertisements

3 Responses

  1. It depends:-)

    Seriously, it depends hugely on the complexity of the source XML and the complexity of the rendering transformation originally used to to produce the high res PDF.

    More information required 🙂

    Sean

  2. Yes, the beauty of XML should be that it’s plain text, human readable. Simple edits should be able to be made in any text editor. In well written XML tag names should be obvious. or are usually well understood. If you have obscure tagging schemes, then those should really be documented.

    However, I’m sure that the transforms are probably where you’d end up with problems if you wanted to make any massive changes.

    It’s never about what it takes to get the job done, it’s about can someone come in behind you and work with your code.

  3. Hi Sean and John. According to the people who wrote our FO, it’s the “most complex one they’ve ever seen.” Nice. The content model itself makes perfect sense to us, because it reflects our products. The tag names and the concept around how they all fit together aren’t that obvious to outsiders though. We have documentation and in the past when vendors have had to work with our XML, they’ve eventually got it. But in the case of reprint corrections, the project is too small for them to get acquainted with the content model, and definitely too small for them to develop their own transformations to get it to output.

    As for the corrections themselves, if they’re just text corrections, then anybody could do them in a text editor as you point out. I’m actually not sure that that’s the extent of it though since I haven’t been provided with them yet. If stuff needs to be moved around on the page or other big restructuring has to happen, the problem of familiarity with the content model comes into play again. I’m crossing my fingers that’s it’s just text changes which can be done in the PDF files. Then I’ll gather the corrections and stuff them in a folder to go in the archive, so if we ever need to use the XML again we’ll know that corrections will have to be made. The “what could possibly go wrong” solution seems the most workable–if it’s just text corrections. If they go deeper, then even the PDF solution may not work, so we’re back to finding someone to work in the system to fix the XML. More to come, I guess.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: