Category Archives: XML editor

XLink FTW, Part 2

Reading through my yesterday’s blog entry on XLink, I feel there are things I need to clarify. In no particular order, here goes…

  • I think that a schema of some kind (speaking in the general sense and thus including anything from DTDs to XSDs) is always necessary for XML to work well. I know, that sets me apart from quite a few of the young whippersnappers in XML today, but I never consider the well-formedness advantage an advantage when it was marketed as such. But then, I’m a dochead, to borrow Ken Holman’s terminology.
  • Namespaces frequently make life difficult, especially for those of us who feel that DTDs are superior to XSDs. Those pesky namespace attributes often keep popping up when processing XML, resulting in bug reports from desperate technical writers. And they all know my mobile number, it seems. However, namespaces really are a must in these days, regardless of your refusal to import foreign namespaces to your XML, because most of XML’s really useful sister recommendations depend on them.
  • I do consider data typing in XML to be largely unnecessary, if we stick to using XML for documentation and publishing. Only rarely have I felt the need to include data typing in a schema, and in most of those instances I have been proven wrong by more sensible colleagues (or come to my senses on my own, resulting in the quick removal of unnecessary data types in my XSD).
  • It is a pain to implement XLink in an XSD, but largely because of reasons that have nothing to do with XLink as such and everything to do with problems with namespaces (such as the problem hinted at above). Plus, of course, the fact that different XML editors still seem to implement different parts of the XML Schema recommendation in differing ways (or not at all).
  • DTDs, on the other hand, work like a charm with XLink attributes added, provided that your tools follow the XML spec. I have experienced problems with MSXML and its derivatives, which proves my point.

Thank you for reading.

Oxygen 11 and an Old Bug

Oxygen 11 is out and I just installed it on my laptop. It’s still the best XML IDE there is, by far, but I’m getting a bit annoyed by a bug that has persisted for a year now.

Long story short, but basically the tabs bar that keeps track on the open documents and indicates the current document is buggy and will not correctly focus on the current document if that document is too far right to be visible without scrolling, and a previous document, also too far right to be visible without scrolling, has just been closed. The bar and the actual visible document do not synch so while the document itself is open and editable, the tab is missing. Very annoying, to say the least, if you are working with a highly modularised stylesheet and need to have more than a handful documents open at the same time. Apparently the bug is in a third party component and until that component is updated or replaced, the bug will persist.

I can live with that bug, though, and the new version seems to have enough fun stuff to keep me busy for a while. XProc support, for example, is a welcome addition. I’ve been wanting to try it ever since Norman Walsh presented it at XML Prague, and now there should be no further excuses.


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.


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.

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.

Oxygen 9.0 Is Out

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.