I’ve been trying to make XMetaL 3.1 work on wine 1.0, and have to say that I miss the days before the wine team replaced Internet Explorer with a wine-specific solution. Specifically, it appears that ActiveX handling has been changed to the worse.
I don’t know what’s wrong but I can no longer make XMetaL to run on my Debian/GNU Linux box.
Read CNN’s web page, just now, and found the following, re the US presidential election:
McCain, meanwhile, continues to hammer his opponent for exuding confidence in the final days of the campaign. He has been repeating a standard campaign line recently, saying Obama is “measuring the drapes” for the White House.
My immediate reaction was: What’s wrong with confidence? I don’t understand. If you think you’ll win or, God forbid, if you think you’re right, what’s so terrible about it?
8.
Still makes me giggle. For those of you not in the IT business, move on to the next blog.
I’ve been thinking about DITA, partly because of the comments from Michael Priestley regarding my previous DITA post, but also because I recently had to prepare a quote for a prospective client.
On one hand, I still maintain that a generic structure can practically never be as immediately relevant to a client than a structure tailored for their needs. I’ve seen this happen many times in the past, having to compare various so-called industry standards with the actual needs of my clients. Structures have mapped poorly, which is to be expected, but the same has been true with meta-data which, in a way, is more surprising, considering that meta-data should be something the industry standards get right.
On the other hand, recently, after my latest DITA blog, a prospective client requested a quote for replacing their current CMS. They’ve been authoring topic-oriented pieces of information for online publishing, with the topics sometimes collected in larger PDFs printed out and placed in binders. What they wanted was better version handling, integration with PDM applications, and an environment that would better support the authoring of individual topics published in various contexts. There was very few obstacles in the way of company-specific structures or meta-data.
Individual, loose topics, published in various contexts and deliverables, mostly online, sometimes on paper but as collections in binders. Hmm… where have I heard this line of thinking before?
Knowing how several editors out there have feature-rich DITA support and are easily adaptable, the quote was quite easy to prepare. It’s certainly easier to offer a figure when many of the unknowns are already taken are of, and this one practically screamed DITA.
Maybe the RFQ was a practical joke from the DITA folks. You’d tell me, right?
Recently, I bought a new computer. It’s the modern kind, with a dual-core, 64-bit, processor, an Nvidia graphics card, a huge SATA drive, and everything else I could think of when placing the order. And of course, I installed the amd64 Debian GNU/Linux distribution, envisioning fast and trouble-free computing using my favourite Linux distribution.
Well, so I thought. Then I started putting all those small support programs in place, from Flash to Skype, and realised that none of them would install. See, they are 32-bit, made for 32-bit operating systems, and there are no 64-bit versions for Linux available.
Why is this?
Mind you, it is possible to run most of these in “32-bit mode”, using 32-bit libraries, but you also need a steady supply of Aspirins and such, because it takes a lot of extra work, tinkering, and cursing.
If a piece of software was truly open source and free, as in “free speech” (as opposed to “free beer”), someone would immediately rectify this by compiling a 64-bit binary for others to use. And if that binary had problems, someone else would come along and fix that, often in a matter of days, not to mention adding features and fixing bugs in the original.
As many Linux users will testify, this works extremely well. Me, I’ve been using open source for years now, professionally and privately, and have experienced significantly less downtime than many of my colleagues and friends stuck with commercial software, often from that large Redmond manufacturer, in spite of the fact that my Linux variant is Debian’s development branch, codenamed Sid (named after the kid from Toy Story who liked to break toys).
Yet the makers of those small bits and pieces of software that many of us rely on, software that some insist are “free”, will not provide the large 64-bit Linux user base with 64-bit binaries, or make available the source code so others can provide us with that service.
Why? And what’s free about these programs, anyway, when you can’t do what you want to with them?
For the last year or three, XML editor makers have been busy coding DITA customizations into their products. The latest editor to get DITA is Oxygen, my XML IDE of choice these days. It’s the latest fad, see, and there’s money to be made.
But I’m not convinced, and here’s why:
DITA claims to make life easier for users by splitting documents into smaller, reusable pieces, hinting that this is a fresh, new approach to documentation. It’s not, however; some of us have done this for years in our DTDs, long before XML was even thought of, simply because that’s one of the main points with structured information. It’s the sensible thing to do, a good reason to why structured information is useful in the first place.
Now, this is all good and well, but because DITA needs to appeal to a lot of users, it is a generic structure, and it’s big. Both of these things are unfortunate since bigger means more difficult to learn, both for users and developers, and generic means that to apply the structure to your specific needs, an abstraction (customization) level is needed.
Generic also means that any markup specific to one user’s needs will have to be added, which means more customization.
With DITA comes a package of stylesheets and utilities, also big and generic, hard to learn, and in need of customization, not only to add the user-specific requirements, but also to modify their look and feel. After all, you don’t really want to have your documents look like the next guy’s, do you?
See, what the DITA advocates are saying, basically, is that either you do want that, or you need to customize.
My view of document structures is just the opposite, really. I’d much rather go with writing a customer-specific DTD, if at all possible, just as I’d go for customer-specific stylesheets and other customizations and tweaks. In that way, I could make the structures, utilities, and stylesheets immediately relevant to the customer, thereby saving time spent trying to learn a generic structure and then trying to apply it to your needs.
That customer-specific DTD will practically always be smaller than any generic one; I know every single DTD I’ve ever created has been, including the package of DTDs I wrote for a large automobile manufacturer for all of their aftersales documentation. At the same time the DTD will most likely be far more relevant, far better fine-tuned, for the customer’s needs.
And yet, it would be just as easily customizable as DITA or some other “standards-based DTD“.
When I’m lecturing on XML and document structure management, I always stress that we use XML because we like to convert XML to other formats, not because we want it to remain the same. If some other company needs DITA documents from us, fine! I doubt it, but if the need arises, it’s easy, even trivial, to convert a customer-specific structure to a generic one.
See, DITA to me is just another DocBook. It’s a standard, true, but it’s just another standard among a thousand other standards. It’s open, also true, but so are a thousand others. And of course it claims to be easily customizable, but that’s obviously the case with those thousand other standards, too.
But it’s also big and generic and not very relevant as such to any specific requirement, not without an abstraction level or two.
<rant>
How come a web-based XML editor can call itself a “WYSIWYG editor”? WYSIWYG, per definition, stands for What You See Is What You get, but that’s just madness in this context, for several reasons:
First of all, XML is supposed to be about semantics and structure, not about contents and presentation. The idea is that you present your XML according to your media. On paper, a certain layout is desired, with page numbers, page references, and so on. Online, you need hyperlinks, sans serif fonts, and so on. On a mobile phone’s two-inch screen, you need to break down yur information to short chunks with short titles and captins. And so on.
Furthermore, different web browsers will display a web page differently. A page displayed using Internet Explorer will not be identical to the the same page in Firefox. Sure, they are close these days, but not the same.
And finally, when displaying XML in something other than a pure text editor, you apply a stylesheet of some kind. CSS is common; XMetaL uses it, as does Oxygen. Web-based XML editors often use a combination of XSLT and CSS, so two stylesheets, not one.
Isn’t this the exact opposite of WYSIWYG? You get further away from what XML actually looks like while not getting closer to the published result.
WYSIWYG, in the context of XML and structured documentation, is in my humble opinion a marketing ploy by companies that seem to have little else to offer.
</rant>
I’ve had been busy doing not one but two authoring environments for XMetaL 5.1. I have to say that it’s been a very pleasant experience, in spite for my strong dislike for .NET Studio. I’ve criticized JustSystems for that before, though, so I won’t go there for the time being. Instead I’ll add my more recent (mostly positive) reflections…
The scripting/macro environment is dead easy to use, even for an amateur programmer like me. I’ve created dialogs that change content in various ways while traversing the document tree, I’ve added ID generation code for the my link target elements, I’ve implemented SVG viewing capabilities, and more, mostly without cursing. I’ve stopped trying to delegate every programming task to my colleagues, that’s how comfortable I am with it.
The editor itself is still the best XML editor I know of. If you are a professional (technical) writer there just isn’t anything better available out there. For shorter documents, sure, a text editor will do, or perhaps something like Oxygen, but for anything approaching book length, I much prefer a non-geek tool that allows me to focus on content rather than structure when writing, and structure rather than content when editing.
Found an old bug, though: You can still make XMetaL crash by trying to drag & drop a toolbar button on a new toolbar, if that toolbar doesn’t have the “flat look”. I think this one’s been an issue since 2.0 but I’d have to check my notes to be sure. (Just try exiting the toolbar dialog and KABOOM!)
And finally there’s another little thing bugging me: I have some old XMetaL dialogs that I like to use when needed, created using version 2.0. XMetaL can use them, no problem, but it can’t import them for editing in the new dialog editor. Fairly annoying, in my humble opinion.
I’ve decided to start blogging again. I’m sure you’re all thrilled.
Version 9.0 of my favourite XSL IDE, Oxygen, was released yesterday. Of course, I downloaded and installed it as soon as I could, having waited for an upgrade since 8.2 came out, some six months ago. I’ve written about Oxygen before; it’s the first decent XSL IDE available for Linux, and the more I’ve used it, the more I’ve come to depend on it. See, what I especially like is the fact that I no longer need Microsoft Windows to do my XML/XSL work. Oxygen works very well in Debian/GNU Linux.
And now, it looks like I can finally re-evaluate my XML editor needs, too. So far, I’ve run XMetaL in wine, which kind of works except that right-clicking the workspace still crashes the program (but that’s fairly OK since I seldom need to right-click anything while writing). As most things in wine, it’s beta quality, no more.
Now, however, Oxygen 9.0 comes with a semi-WYSIWYG view, with CSS formatting and start- and end tag symbols, making it the first real alternative to running Windows software in wine. It is reasonably fast, too, from what I’ve seen so far, and certainly more stable than anything run in wine. You do need an official Sun Java JRE, though; it will complain if you use some of the Java replacements available for Linux, and it doesn’t work with the GNU libgcj Java Virtual Machine.
I’ll give it a more thorough test run within the next week or so, but I’m hoping that it can deliver what it promises.