Noster fungitur — ours works. It’s the motto I suggested to a local Mac user group. But it’s also the theme you need to push when selling open-source software against the Microsoft desktop system — Windows 2003 Server with Office 2003. Office 2003, in combination with Server 2003, is the first major Microsoft product to incorporate the company’s vision for an XML-enabled future filled with hot-button features like end-to-end document management.
XML started out as a subset of the standard generalized markup language (SGML) developed for the printing and text-processing industries. XML requires a marked-up document, a document type definition (DTD) — such as HTML — to describe the markup used, and a processor or parser capable of formatting the document according to its embedded markup.
Most web browsers have the information needed to process the HTML DTD compiled, but it doesn’t have to be this way. The more general approach is to have the formatter first read in a mapping file that relates tags to output formats and then read in documents containing those tags for processing according to the definitions in the mapping file.
With this approach, any group cohesive enough to act on shared documentation needs can define its own DTD and rely on generalized XML tools to format documents marked up according to that private DTD.
Microsoft and XML
Document markup languages produced in this way are fundamentally passive. The XML definition governing the creation and use of such DTDs foresaw an independent formatter to process the markup instructions and produce the formatted output.
The formatter — which could as easily be a medieval monk working with pressed gold leaf as a modern knowledge worker using Quark on a Mac — doesn’t change the content of the document. In other words, markup doesn’t affect document portability because you can always strip out the embedded markup to recover the document’s content, even if you can’t exactly reproduce the intended format.
When Microsoft decided to embrace XML, it promptly extended this model to include a wide range of active functions that do affect content. A Microsoft XML document can, for example, call ActiveX components, interact with a DLL or pass tagged content to a Visual Basic script.
As a result, you can use Microsoft XML tools to do things like make documents that automatically update themselves, documents that refuse to be e-mailed to people, not on a predefined list, or documents that delete their own contents if called up after some prespecified date.
This, of course, is no longer XML; it’s more like an embedded remote procedure call (RPC) capability that turns the Office document into a client for server-based processes. As a result, it has traditional RPC weaknesses: Fraud detection can be difficult if not impossible, and, of course, local operation is dependent on the availability of the remote server.
Viral Marketing
In theory, for example, a secured document couriered to you on a write-once CD could be subverted to serve nefarious purposes by a criminal able to spoof a remote server. In practice, this kind of attack should be very rare, but a lot of people can expect to find documents legitimately e-mailed to them rendered unreadable by nothing more threatening than a routine server upgrade at the sender’s site.
Implicit in this issue is the ability to control both the use and the content of a document long after someone else receives it. For example, documents could refuse to display themselves on PCs that fail to meet hardware identification or software-licensing checks, and, of course, the same document could show different content to different people or at different times.
The threat to open source, therefore, is that Microsoft’s XML-enabled documents will represent the ultimate in viral marketing — spreading Microsoft’s desktop system (Server plus Office) licenses wherever documents land. The people who receive these documents from clients or suppliers will have no option except to license the same Microsoft products if they wish to access the full capability of the documents.
Certainly, a Microsoft XML-enabled document opened using OpenOffice.org won’t function as an interface to data stored on a remote Microsoft Server — and users won’t be able to create or modify those documents using a local Linux server running Samba either.
As a group, people who use Microsoft Office generally are willing participants in this kind of viral marketing. To them, the fact that their use of the product forces their clients and suppliers to use it simply confirms the rightness of their own decisions, and it’s the open-source enthusiasts like me who are making trouble by trying to impose our opinions on them.
Ours Works. Now.
It’s important for Microsoft users to understand, however, that when a document becomes an application interface rather than a thing that’s complete in itself, it loses its value as a record of received information. Microsoft users likely will tell you that they have no alternative. Once they do that, however, they’re your sale to lose because there are better open-source alternatives that already work to meet the same needs.
For example, the Cocoon project and its various spin-offs and competitors offer a better way to meet the needs addressed by Microsoft’s promised document management capabilities. The Security Assertion Markup Language (SAML) and other XML work spun out of the Liberty Alliance offer a complete, functional framework for document authentication, user identification, and access authorization that can be used without hardware or software lock-in.
These products work now — people who want to use them can do so without waiting for Microsoft’s Longhorn OS, without waiting for Palladium and hardware identification, and without participating in the usual Microsoft debugging processes. Remember: Noster fungitur. Ours works. Now.
Positive alternatives like this do not, of course, address the negative side of the problem: Your customer can adopt Cocoon on Linux today to achieve most of the goals Microsoft has set for its XML extensions, but what does your customer do when his or her customers send Microsoft XML documents?
Format Gateways
The answer to that is a format gateway. These don’t yet exist, but it’s easy to see how they could be built and used. In firewall mode, a format gateway would run incoming Microsoft XML documents once to freeze and date-stamp their contents before translating them to OpenOffice.org formats and forwarding them to the intended recipient. Similarly, the gateway would reverse the transformation on the way out, automatically handling any needed cryptographic functions and third-party server calls in both directions.
In Web server mode — like the TOM document conversion server — format gateways would accept documents in one format and forward or return them in the alternative format, except that Microsoft Office formats would not be forwarded to addresses inside the organization.
Format gateways would let organizations with thousands of users participate in Microsoft document exchanges while licensing only a small rack of Microsoft servers at the gateway and minimizing both costs and risks through the use of open-source products internally.
Put these pieces together, and what open-source software offers is a better option you can sell using a classic push-pull argument. On the pull side, just cite the fact that the open-source solution works now, costs less, and doesn’t produce either lock-in or guaranteed document obsolescence.
On the push side, just get your customer to think about security and the precedent that Word’s file system revision history sets in terms of the likelihood of having to port all office documents each time Microsoft changes the back-end server processes.
Paul Murphy, a LinuxInsider columnist, wrote and published The Unix Guide toDefenestration. Murphy is a 20-year veteran of the IT consulting industry, specializing in Unix and Unix-related management issues.
Loading ...
