Need to Check Links before Running the OT

>(Re-post) I just encountered a situation that underscores the need for a Link Checking step that runs before the OT. It applies to those of us who are using DITA in organizations that haven't shelled out big bucks for a content management system. [Note: XDocs is the only really affordable CMS there is. It just needs to add Link Checking to be a really stupendous buy.]
In this case, a topic that used to live 3 levels down from the DITA root directory was moved to a new location two levels down.It so happens that the file had links to a keywords file in the root directory. So the conrefs looked like this: ..\..\..\keywords.xml#...

Since the files are under version control (Perforce, in this case) the move was done in the p4v shell, to make sure the VCS knows about the change. But moving the file in that manner naturally did not adjust the links.

Now, XMetaL has some very nice behavior in this regard. When you do a file Save As, XMetaL adjusts all links contained in the file. Any links pointing to the file are still broken (so the behavior isn't quite as good as DreamWeaver's site management capabilities for HTML, but at least all outward-pointing links are corrected.)

Had I been aware of that feature at the time, the right thing to do would have been to:

1. Do a Save As in XMetaL
2. Add the new file to source control
3. Remove the old version from source control and delete it.

Of course, people who aren't using XMetaL don't have that option, so this note mostly applies to them. It's also a cautionary tale regarding the need for link checking tools, due to a couple of subtle OT behaviors.

Subtle Behavior #1: Broken Links are quietly ignored

This is something of a problem, in my book. I'd really like to see some warnings appear when running the OT, or have them show up in a dialog when XMetaL runs it. I mean, it's possible I knew about the broken links.There may even be some writers who work that way as a matter of habit. But dang it, at some point before I publish the darn thing I'd really like to know that some file I haven't looked in a while no longer has the snippet that some topic is expecting!

Subtle Behavior #2: The output hierarchy depends on the upward link paths

So if your ditamap is in ROOT, and you publish to ROOT/out, then your output file (say, a PDF) normally goes to ROOT/out--but only if there are no links in any of the topics that go any higher than ROOT. So a topic can link to ROOT/keywords.xml, or ROOT/common/snippets.xml, or to any other file in the ROOT hierarchy, and the output goes where you expect.

But if any link goes to a directory higher than ROOT, then the directory necessary to make all links work is replicated, and the output PDF winds up going to ROOT/out/ROOT.

That behavior is something I complained about, once upon time, because it was something I didn't want for the project I was on. But now I'm on a more normal project, so that behavior is ok.

That behavior was especially ok in this case, because it was the reason I found the broken links!

Summarizing...

• The OT did not complain that the links were broken.
• An extra level of hierarchy was created in the output directory, even though the links were broken.
• The hierarchy-change raised an alert wrt to the broken links--but, had the links been broken in a different way, there would have been no warning at all.

Clearly, it is a darn good idea to run a link checking tool before running the OT. Because only an eagle-eyed inspection of the generated output will spot what should have been the (possibly very small) results of a conref.

The only other alternative is to open every file in an editor that will give you a warning (like XMetaL's "refresh all references" feature). But that's a repetitive, manual task--and that's what computers are for.

So now I've got to get to work and build me a Ruby-based link checker over at my RuDI project. It must be time, I spent several sleepless hours last night thinking about how to do it. And then today, I run into this problem. It's an omen!

P.S.
I know Dick Johnson had a tool of that sort somewhere on the web. Anyone know where that is? Perhaps there are other options, as well?