Site FeedPalimpsest has moved. Please visit our blog in its new location for the most recent posts from Scriptorium.
Palimpsest
Publishing DITA without the DITA Open Toolkit: A Trend or a Temporary Detour?
Monday, December 01, 2008 — posted by Sarah O'Keefe
I estimate that about 80 percent of our consulting work is XML implementation. And about 80 percent of our XML implementation work is based on DITA. So we spend a lot of time with DITA and the DITA Open Toolkit.I'm starting to wonder, though, whether the adoption rate of DITA and the DITA Open Toolkit is going to diverge.
For DITA, what we hear most often is that it's "good enough." DITA may not be a perfect fit for a customer's content, but our customer doesn't see a compelling reason to build the perfect structure. In other words, they are willing to compromise on document structure. DITA structure, even without specialization, offers a reasonable topic-based solution.
But for output, the requirements tend to be much more exacting. Customers want any output to match their established look and feel requirements precisely.
Widespread adoption of DITA leads to a a sort of herd effect with safety in numbers. Not so for the Open Toolkit -- output requirements vary widely and people are reluctant to contribute back to the Open Toolkit, perhaps because look and feel is considered proprietary.
The pattern we're seeing is that customers adopt the Open Toolkit when:
- They intend to deploy onto multiple servers, and open source avoids licensing headaches.
- The Open Toolkit provides a useful starting point for their output format.
- They need attractive PDF. Getting this result from the Open Toolkit isn't quite impossible, but it's hard. There are other options that are faster, cheaper, and easier.
- They need a format that the Open Toolkit doesn't provide. The most common requirement here is web-based help. Getting from the XHTML output in the Open Toolkit over to a sophisticated tri-pane help system with table of contents, index, and search....well, let's just say that it keeps me gainfully employed. AIR is another platform that we need to support.
- Adobe FrameMaker can output lovely PDF from DITA content through FrameMaker (no Open Toolkit). You can also use the Open Toolkit to generate formats such as HTML.
- ePublisher Pro uses the Open Toolkit under the covers, but provides a GUI that attempts to hide the complexities.
- MadCap's software will support DITA (initially) by importing DITA content and letting you publish through MadCap's existing publishing engine.
- Several other vendors provide support for publishing DITA, but do not use the Open Toolkit at all.
- Set up an XML-based authoring workflow
- Manage XML content
To me, the interesting question is this: Will the use of proprietary publishing engines be a temporary phenomenon, or will the Open Toolkit eventually displace them in the same way that DITA is displacing custom XML structure?
Labels: analysis, dita, ePublisher Pro, madcap
9:00 AM Permalink | |
Update: ePublisher Pro license
Thursday, May 24, 2007 — posted by Sarah
This evening, Quadralay's Vice President of Sales posted some additional details about the licensing program in the wwp-users group (message available here, but only if you are a member of the group). He also pointed to a PDF version of the EULA, available here.This agreement, dated May 24, 2007, removes the most onerous provisions that I described in an earlier post. In particular:
- The auditing provisions have been removed entirely.
- The definition of "user" now includes:
A “user” under this EEULA shall be construed broadly to include anyone to whom you permit access to design/maintain stationery by use of the Software; or publish content by use of the Software; or create/modify a source document that is published by use of the Software.
By the standards of the previous license, this seems almost reasonable.
Almost.
The content development process is increasingly complex. Two scenarios that don't fit the new model very well are:
- An organization with numerous part-time content contributors for whom writing is only a small part of their responsibilities.
- An organization where some documentation is generated from code comments and then commingled with information written by technical communicators. In that case, is every developer a "user"? What if the documentation is generated into DITA XML and then pushed through the ePublisher DITA adapter?
An important note to include here is that these users are defined asIn the case of a FrameMaker-based workflow, the SMEs rarely have access to the FrameMaker source files directly. But in a Word or DITA-based workflow, SMEs often "modify source documents."
those that create and compile source documents. Those people in the
organization who only contribute content to source documents are not
considered users. So if you are an SME [subject matter expert] or you write code or text that gets placed into a source document, you are not required to be licensed.
Finally, there is no pricing available on Quadralay's web site. To get a quote, you must fill out a form and contact Quadralay.
I still think the correct answer is to take a hard look at a standards-based workflow with XML and XSL.
Labels: ePublisher Pro
8:00 PM Permalink | |
Water from a stone?
— posted by Sarah
(Update: Overtaken by events. See the post here.)Nobody noticed back in June 2006, but Quadralay has a new license agreement for ePublisher Pro.
Because of the relatively high price of ePublisher Pro (and previously WebWorks Publisher Pro) licenses, it's common for an organization to purchase fewer licenses than there are writers and then set up a dedicated "conversion machine" that runs ePublisher Pro.
Under the new licensing approach, this is no longer allowed. Instead, the license is determined by counting the number of users of ePublisher Pro. I can make a reasonable argument that Quadralay has a point with this approach and in fact, this was tried by RoboHelp for FrameMaker at one point. But unfortunately, the ePublisher Pro "users" are determined by a truly audacious method. Here is an excerpt from the licensing agreement:
1.4. A “user” under this EEULA [Electronic End User License Agreement] shall be construed broadly to include anyone to whom you permit access to author, co-author or materially modify a source document that is published by use of the Software and anyone to whom you permit access to review such a source document for accuracy, concurrence or approval.In other words, a user is anyone who touches content that is later converted through ePublisher Pro.
But wait, it gets better:
6. Compliance Records and Measures.I have posted the entire EULA (from version 9.2 build 9054) here (RTF format) so you can read it in its entirety.
[...]
B. Records. Accordingly, you agree to track the number of users as defined in this EEULA and to maintain reasonable records of such users, including usage logs or other records, sufficient to show at least the identity of any users and a time record of any instance of use. Any user will be presumed to be an author, to have made material modifications and/or to have reviewed for accuracy, concurrence or approval unless the End User is able to show otherwise by clear and convincing proof.
[...]
D. Confirmation of Compliance. You acknowledge and agree that Quadralay has the right, upon written request, to receive reasonable confirmation of the actual number of users in any calendar quarter and, if such confirmation is not reasonably satisfactory to Quadralay, then once in any calendar year Quadralay may audit user logs or, in the absence of user logs, other records or indications of the number of users sufficient to show the identity of users, a time record of all instances of use and, if you dispute whether any instance of use constituted use as defined by this EEULA, then sufficient information to show the nature of the use.
This is truly unbelievable. I don't quite know where to start, but let's tally the problems from our perspective as consultants:
- The auditing provision entitles Quadralay to user logs, which means we are potentially exposing our customers (who might not even use ePublisher Pro) to fishing expeditions from Quadralay. I'm no lawyer, but I assume that this provision conflicts with non-disclosure agreements that we have executed with our customers.
- The definition of a "user" includes authors, editors, indexes, and reviewers. It's unclear whether it includes people who, for example, review a PDF version of a document generated in FrameMaker, which is later converted to HTML through ePublisher Pro.
- The requirement for "user logs" appears to apply to the source documents, which means that we are required to keep track of who looks at FrameMaker files, which are potentially unrelated to the ePublisher Pro content.
- A content management system could keep track of these issues. This seems like possibly the worst reason I've ever seen for implementing a CMS.
My advice is simple. Take another look at XML and/or structured FrameMaker. The cost of building XSL transformation templates may suddenly be more appealing than the cost of getting and staying in compliance with this new licensing approach. And furthermore, XSL is an open standard, so you eliminate the licensing risks of commercial software so eloquently demonstrated by Quadralay's new EULA.
When companies have limited budgets for software, they come up with creative solutions (like dedicated "conversion machines"). When those approaches are ruled out, they will find another way to mitigate the cost. Responses so far range from, "so what, they can't enforce it" to "We're going to take another look at Flare."
We are in discussions with Quadralay about how our unique situation as consultants should be handled in licensing. Stay tuned...
Labels: ePublisher Pro
5:28 PM Permalink |