Jon Udell wrote yesterday that we should really be getting beyond the office document format debate swirling around the Massachusetts decision, because all heavy footprint authoring applications are headed for oblivion in our increasingly net-software-as-service world. (David Berlind also weighs in on the death of fat clients apps.) Tim Bray is skeptical because “… authoring software is hard.” While my view of the ODF debate is much closer to Jon’s than Tim’s, I agree with Tim’s caution here. While my coding skills were never in the league of either of these guys I have spent a lot of time working on authoring software, and more importantly, collecting requirements from users. Admittedly this was well before the Web existed, but what hasn’t changed one bit, is the need for authoring software to meet a staggering array of complex user requirements. Authoring software has to be flexible and extendable to meet the always unanticipated user needs. Authoring software is hard, and differing formatting and integration requirements will keep it that way.
Note that extending software functionality is not unrelated to extending the encoding of the content, which reminds me that…
Ironically, the reason I agree with Tim here is exactly why I disagree with the ODF decision: extensibility should be the first requirement of a government decision on an open document standard, and ODF looks uncomfortably like a limited implementation. From a practical point of view, scope is critical, but as Jon says, “In theory, governments should mandate standards, not implementations.” Perhaps the way to think about it is that governments should mandate standards (XML) but adopt implementations (form OASIS and Microsoft and perhaps others). Realistically there will be multiple versions (implementations) of each anyway, so a single implementation will never be enough.
Category: Web technologies & information standards (Page 41 of 58)
Here we include topics related to information exchange standards, markup languages, supporting technologies, and industry applications.
Two of the topics in the title are things we normally don’t touch in this blog. However, the tempest over Massachusetts’s OpenDocumentFormat decision is inflaming passions almost as much as religious and political issues do. In fact, I am writing about it because I woke up irritated at how ill-informed and irrelevant so much of the discussion about the state’s decision is. (Not a good way to start a blog entry!) I promised myself not to go on for more than the length of a reasonable blog-entry, so rather than dig into all the weeds, here is a short history lesson to bring out the big picture, and hopefully keep the debate focused on the real issue for Massachusetts’s and others contemplating similar decisions.
When we (in the standards community) debated open document standards 20 years ago, there was a religious and political fervor fueling the arguments of both sides. Our side (the SGML side, which included Tim Bray and Jean Paoli, now the chief XML people at Sun and Microsoft respectively), argued that nobody’s content should be held hostage by being stuck in a vendor’s proprietary format, and that the solution was a standard set of rules for describing whatever kind format was necessary that vendors were free to implement. The other side (the ODA “Office Document Architecture” side) agreed with that, however they thought the solution was for a bunch of vendors to get together and agree on a format that, instead of being proprietary to a single vendor, was proprietary to a self-defined group of vendors. This solution was even worse than the status quo for lots of reasons (lowest common denominator functionality, enhancements by slow international committee, unhealthy cabal-like motivations, …). At the time I thought of ODA as the soviet approach, and the SGML approach as the democratic approach. Fortunately, the SGML approach won, and that set in motion the developments that have given us XML today.
You can tell where I am going with this. But there is one more relevant aspect of this history to mention. One of the main arguments behind ODA was that the SGML approach was just too difficult to implement. They had a point, you have to pay for the freedom of flexibility. Their mistake was thinking there was an alternative that could anticipate all reasonable requirements. It can cost even more when you just can’t implement what you need to.
The situation today is a little different, but the need for organizations to be able to do whatever they want with their own content is exactly the same. The imposition of any single schema/format on all documents in any organization simply won’t work. Anybody who has been involved in helping organizations build IT applications knows that exceptions are the rule, and you can’t legislate them out of existence even in authoritarian corporate environments. A good decision for the state would be to simply require all documents to conform to one of a number of publicly documented and freely available XML Schemas – who cares what software did or did not create the content or did or did not design the schema? Certainly there are some complex details to work out, but there is no mystery.
We have had debates on this topic at our Boston conference last year and in San Francisco in the Spring, where there was more agreement than disagreement between Microsoft (Jean) and Sun (Tim) and the issues raised were refreshingly free from politics. It’s too bad we didn’t record it.
There is plenty of coverage on this topic. We have more comments and pointers, but also see Jon Udell and David Berlind.
If you haven’t yet visited KeyContent.org, check it out. It is quickly becoming an incredibly useful wiki on issues related to technical communication, information architecture, and web design. Directors Bill Albing, Rick Sapir, and Sherry Steward got the ball rolling.
Writing for SearchDomino.com, Peter Bochner puts IBM’s acquisition of XML hardware vendor DataPower in perspective. For Bochner and Zapthink’s Ron Schmelzer, the goal is to bolster WebSphere performance. But I think there is a broader story here, and the article itself points out that both Intel and Cisco have gotten into the XML hardware game.
CM Professionals founding director and all-around great guy Bob Doyle has a cute take on DITA in the current EContent Magazine newsletter. Bob makes a lot of very good points, and also offers perhaps the best plain-English explanation of DITA’s value to implementers I have read:
While it is doubtful that out of the box DITA will find widespread use without customization (called specialization in DITA speak), the ready-made generic topic, and three “information-typed” specializations called concept, task, and reference, will get documentation teams producing very quickly. These documents will also be easily exchangeable with others. Because specializations inherit (thus the Darwinian name) properties from the general topics, their default behaviors–like printing, conversion to PDF, or XHTML Web pages–will produce decent results when transformed by default DITA XSLT style sheets.
One detail deserves mention though in Bob’s writeup. He refers to a “rumor” that Adobe recently used DITA to produce documentation. We know this rumor to be true, and have written about how Adobe used DITA to produce localized documentation for the recent release of Creative Suite 2. And, to all of Bob’s positive points we can add this one–at least two major companies (Adobe and Autodesk) have already used DITA to produce major documentation releases. Interestlingly, both Adobe and Autodesk used the same core technology to work with DITA–FrameMaker on the authoring side and Idiom World Server for content management and localization.
If you have been hearing about Ajax technology and are curious, you might want to check out this pretty cool dictionary site. The developer offers a helpful explanation of how it works, including some potential risks and tradeoffs. Up until now, Google Suggest has been kind of the canonical example of Ajax for this kind of application, but I think I like this one better. Some of the bloggers over at ZDNet have been doing a nice job of explaining Ajax and other such technologies and how they will impact traditional applications such as Microsoft Office. I think there are all kinds of implications for content management, with authoring and search interfaces only the beginning.
FrameMaker 7.2 was announced this week (see our news here and Adobe’s home page for the product here). Our news story touches on many of the new product features, but a few things are worth highlighting. Overall, the release is a significant step forward for FrameMaker, and should be seen as very welcome news for organizations that rely on the product for technical publishing.
- The new release adds XML schema support. While Karl Matthews, Adobe’s Group Product Manager for FrameMaker, was careful to point out to me that the schema support does not extend to data typing, I think this is sufficient for the kinds of publishing applications FrameMaker users would develop.
- The product now includes XSLT support. XSLT transformations can be invoked at the time a structured FrameMaker document is opened or saved. This will enable, for example, a “save as” function that could invoke an XSLT transformation on an XML document to create other content sets, metadata extractions, and so on. This is a clever addition to the product, and gets FrameMaker developers away from being reliant on the FrameMaker SDK.
- The product comes with a starter application for DITA. This is also welcome news, as there is a groundswell of support for DITA, and an independent group had been working on a separate FrameMaker application for DITA. This gives FrameMaker users a DITA application supported by Adobe. Moreover, the FrameMaker DITA application reflects a great deal of work Adobe had done in-house using FrameMaker to produce the documentation set for Adobe Creative Suite 2. (For Adobe’s own case study of how they used FrameMaker for this project, you can download this pdf. A related case study at Idiom’s web site describes how FrameMaker was used with Idiom’s WorldServer technology to manage the localization of the documentation into many languages.)
- The new version also adds some additional features and functionality for migrating unstructured FrameMaker content to XML. They have a pretty useful Migration Guide here (pdf).
On the whole, I was impressed with what I learned about the new release. It has some important new structural features (schema, XSLT), and the DITA application is timely and useful to a growing number of potential users. The strength of this release should quiet some of the feelings among users that Adobe is not fully committed to FrameMaker. Moreover, at a list price of $699, FrameMaker continues to provide a great deal of value for its user community by combining XML editing, high-quality print publishing, well integrated support for Adobe PDF, and support for multichannel publishing.
We keep seeing lots of interest in DITA, the Darwin Information Typing Architecture. One sign of growth is the emergence of several regional user groups. Mark Nazimova invites people in the New York City area to a kickoff meeting of NYDUG (the New York DITA Users’ Group).
The first meeting is on Tuesday, September 13, beginning at 6:30 p.m., at Information Builders’ headquarters at 2 Penn Plaza in Manhattan. The location is directly above Penn Station in midtown Manhattan (24th floor). It’s convenient to most subway lines, LIRR, New Jersey Transit, just down the avenue from the Port Authority Bus Terminal, just down the street from PATH, and two subway stops from Metro North.
Mark asks that you RSVP. If you are coming, he will need to give your name to building security; if you are not coming, he would like to hear from you if you are interested in DITA and in the tri-state area.
We have written about Information Builders and its use of DITA in a white paper, Topic-Oriented Information Development and Its Role in Globalization.
Subscribe to the Gilbane Advisor
