I’ve been hearing that Quark is on its last legs since, well, about the same time as when the “FrameMaker is dead” rumor got started. But the news of the “unexpected” departure of the CEO at Quark can’t possibly be good news:
I have a pattern of learning things The Hard Way. That is, get a book, dive in, and just do it. Eventually, some order emerges from the chaos, and one day, it all starts to make sense. This approach has failed once or twice — my ill-fated attempts to learn Perl come to mind.
When I needed to learn XSL a few years back, I expected something like the Perl experience — a language that was unintuitive, annoying, and occasionally painful. To my surprise, I discovered that I actually like XSL!
The XSL language is build on templates. You define a processing template for each element in your XML source file. This means that you can build up your XSL transformation a little bit at a time. You can start with the easy search and replace stuff and move up to more challenging issues, such as building hyperlinks from cross-references, creating tables of contents, and sorting indexes.
In September, I will be teaching our first Transforming XML Content with XSL class. The class will build up just as I’ve described, starting with the easy stuff and moving up to rather complex transformation requirements. We will focus on things that need to be done for publications: paragraphs, inline elements, inline tables of contents, navigation, indexes, and attractive formatting.
I’m interested in feedback on the syllabus.
I often make the point that content is more challenging to structure than data. In this article, you see the same point being made from an IT-centric point of view. Interesting stuff.
Today, a caller inquired about configuring FrameMaker on a server. I told her that required a special server license from Adobe. “Oh, but we don’t want to buy copies of FrameMaker for everyone’s workstation. That would be ridiculous!”
It turns out that Anonymous New Yorker (trust me, you couldn’t miss the accent) has purchased one copy of a FrameMaker training workbook, which she plans to provide to her entire office. “They’ll be sharing.”
I declined to provide instructions on how to best configure this server-based installation, pointing out that Adobe’s license — and ours — does not allow such usage.
ANY’s response? “Well, I’ll see how it goes, and if I have any problems, I’ll call your tech support department.”
A suggestion: If you’re planning to use software illegally, don’t call me for advice. And please don’t rub it in by pointing out that you weren’t willing to cough up a measly $119 per employee.
So, how about it, readers? Is this just how the world works?
The state of the XML tool universe is…strange.
In one corner, we have enterprise tools with enterprise price tags and enterprise implementation costs. This corner consists of the following
- Big, expensive content management systems (think Vasont and Documentum)
- Big, expensive served-based content production systems (think Arbortext)
- Massive, expensive implementation effort
And in the blue corner? Open source tools for those of you who like to tinker (or “basteln” as the Germans say):
- Open source content management
- Open source XML editors (list includes commercial, free, and open source tools)
- Open source XSL processors (Saxon, FOP)
- Massive tinkering to glue everything together
In the middle? A couple of commercial tools that offer:
- Lower implementation cost
- Less automation than the enterprise level
- More production-ready out of the box than the free stuff
Finally, we have the category of Tools that Save Content in XML But Aren’t XML Authoring Tools. These include AuthorIT and the not-yet-released MadCap Flare. They are either XML-based (Flare) or can produce XML (AuthorIT). But they do not meet my definition of an XML authoring tool, a tool that allows you to define a structure and then create content that follows your structure.
All in all, the current state of the tools just seems odd. The vast majority of content creators who need XML must fall somewhere between the extremes of enterprise-level implementation and the “build-your-own” approach. And yet, the buzz seems to be at the edges or with the We Produce XML Files category.
What am I missing?
Jim Rapoza at eWeek had an interesting suggestion in regard to the Adobe/Macromedia merger. He notes that the sorting and sifting that follows most software mergers leads to some products fading away. Some actually get a funeral but often there is simply a loss of interest. Rapoza suggests turning over these orphans to the open-source community.
This probably sounds like folly. Companies just don’t do this sort of thing. However, IBM has certainly demonstrated that moving technology to the open source community can be a valid business strategy.
I have seen an acquiring company become “a deer in the headlights”–as the cost of maintaining/enhancing a product is weighed against the cost of offending customers by killing it. The latter cost isn’t taken lightly since these customers probably license software from both companies. It is not unusual to see critical business applications and processes that have been built around the specialty tools that are most likely the targets of such “alignments”. The integration investment often significantly exceeds that of the underlying tools.
Just a few short years ago this wasn’t even an option. Perhaps Rapoza is onto something.
I was listening with half an ear to NPR’s Weekend Edition when the puzzler segment came on. During the interview, we hear that the winner, Judy from Lexington, Mass., “leads a group of technical writers at Sybase.” After that, they had my undivided attention as Judy made her way through a tricky set of questions.
I’ve always thought that technical writers and other professional word people should be good at these puzzles. This is the first time I’ve heard a player identified as a technical writer.
At the STC conference, I used my handy camera phone to take a picture of Adobe’s FrameMaker booth, complete with FrameMaker product manager. I planned to post that picture here.[envision the lovely FrameMaker booth with Adobe representation]
Unfortunately, the phone ate the picture. You’ll have to take my word for the following:
- Adobe was represented at the STC conference.
- The booth had FrameMaker signage.
- The FrameMaker product manager was present in the booth.
I also ran into numerous friends and colleagues, including:
- Dieter Gust and Michael Plattner of ITL (German page, English page). Among other things, they have been organizing FrameMaker user conferences in Germany for the past decade or so.
- Paula Berger, the incoming Second Vice President of STC. Paula was last seen running into a session because she was late. And on the panel. Paula should be a contestant on Overcommitted Idol.
- Nick Rosenthal of Salford Translations, who is more fun to hang around with than anyone in the localization business should be.
- Joe Welinske, who was likely scouting for next year’s crop of presenters.
- Folks I would loosely characterize as Fellow Consultants: Alan Houser, Neil Perlin, Kit Brown, Dave Kmiec, and others.
- I ran into a surprising number of North Carolina-based folks, which led to some major cognitive dissonance. But thanks for sharing your umbrella, Greg!
- People I have Trained: Donna C., Justin B., and others
- People Who Wanted to Ask Me Questions
- Apologies to anyone I missed. It was a crazy couple of days.
The interview includes some information about Flare, the RoboHelp replacement tool that MadCap is developing. Flare is billed as an XML-based authoring tool. Mike Hamilton describes the competitive landscape like this:
There are a lot of XML tools and workflows out there, but they either fall into the “you better really know what you’re doing” camp of editors designed for programmers or they fall into the enterprise camp where it takes a lot of resources to set up a system, create custom/proprietary transforms, maintain the system, etc. Many small to medium sized companies don’t have the in-house expertise to build and maintain such systems. MadCap Flare is designed to fill that gap in between. Will MadCap Flare create XML files – yes, but the author doesn’t have to even realize this. Will MadCap Flare provide transforms to repurpose this XML content into other useful formats – yes, but the author doesn’t need to know what the term transform means, let alone have to know how to write one. MadCap Flare will be an affordable, shrink-wrap, turn-key solution.
Thus, we have a Goldilocks approach to XML tools: too small (for programmers and XML data), too big (scary enterprise tools), and just right (Flare). This misses a critical distinction. XML is a file format that provides a vendor-neutral way of exchanging content. In addition, XML’s file format supports structured authoring, in which you define a set of rules for your document and then enforce them. If you want to implement structured authoring for your organization, your authoring tool must support the definition and enforcement of your document rules. This is usually done with a document type definition (DTD) or schema file.
To provide structured authoring support, a tool needs the at least the following basic features:
- Lets you create structure rules
- Enforces structure rules in your documents (validation)
- Lets you define and supply metadata for the document components
Flare will provide XML support, which means that it should be relatively easy to extract information from Flare for repurposing elsewhere. But I haven’t seen anything that indicates that Flare will support structured authoring.
For more on structured authoring, see our XML and Structured Authoring white paper (free, but registration required)
(Interview found at Keith Soltys’ Core Dump)
A PowerPoint file with their slides is available here.
If you’re considering structure implementation, and want to do it fast, this is worth a look.