Author Archives: admin

elementNames and attributeNames

I keep getting annoyed by the (Java-inspired) naming of elements and attributes in some people’s XML, where the names contain capital letters to help keep the names clear. I’m sure you’ve seen how it works: elementName, attributeName, myNewAndExcitingElement, ohLookICanCreateReallyLongQNamesForNoApparentReason, ad nauseam.

Why do they do this? I know there is some kind of rationalisation for it in the world of programming languages, but in XML? XML is not a programming language and I still think it should be understandable and usable by humans (I know; SGML was supposed to be human-readable but XML doesn’t have that requirement). If you find yourself writing XML in a text editor (still happens to me), not only are these names enough to drive anyone nuts but they also make the XML more error-prone because you’re bound to spl something wrong. And if you write your XML in an XML editor, the element names filling the start and end tag symbols take up a lot of space that should be left to the actual content. (And no, I don’t believe in the minimal tag symbols that some editors provide; I want to actually see the tag names and I want to see the attribute names. They help me structure my document; in fact, they are there for that purpose!)
I ask again: why? If you are writing a schema and need to name an ordinary paragraph element, surely you don’t need to name it ordinaryParagraph or even paragraph? In my schemas, p is more than enough.
SoPleaseUseShorterNamesWithoutResortingToSillyConventionsBorrowedFromElsewhere.

Göteborg Film Festival

For 11 days every year, I take time off XML and the IT business to show films at the Göteborg Film Festival. I’ve been involved in the festival since 1987 and showing films at the Draken Cinema (for the festival; I’ve worked at the place for longer than that in other contexts) since 1990.

In just over two weeks, it’s time for my 21st consecutive festival at the Draken.

Finally, a new Intel Xorg driver in Debian Sid!

As most Intel video card users on Linux will know, the Xorg drivers have regressed significantly during the last year or so. From a reasonably stable driver with (mostly) expected performance and functionality, we’ve become accustomed to, well, a mess. For every bug fix, something new seems to break and I for one have become increasingly reluctant to upgrade unless I have to.

This time I really had to.

The new driver does seem to take care of the disappearing mouse pointer bug where any resolution higher than 1024×768 would make the pointer vanish. I had hopes it would also be able to recognise the correct resolution for my laptop when it is docked to an external screen (which the stable driver does without a problem) but no such luck.

Performance is still slow, too. The extra bells and whistles on KDE 4.3 just aren’t possible if you want a desktop you can work with. I don’t think they are that heavy on the system, it’s just that the Intel driver sucks.

Still, for the first time in months, the new driver means an actual improvement.

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.