Friday 29 August 2008

64-Bit "Free"Applications

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?

Monday 25 August 2008

DITA

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.

Tuesday 12 August 2008

WYSIWYG Rant

<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>

Thursday 7 August 2008

XMetaL Revisited

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.

Wednesday 6 August 2008

I'm Back!

I've decided to start blogging again. I'm sure you're all thrilled.