Today it occurred me to have a look at the DITA Architecture Specification source to see how the people behind the spec would tag a list; as some of you know, this was the subject of my recent blog entry. There are a number of lists in that spec, many with introductory paragraphs, so it’s a pretty obvious way to find out, right? Well, after the examples in that spec, maybe.

Anyway, this is how they do it:

<p>Introductory para:
<ul>
<li>Item</li>
<li>Item</li>
</ul>
</p>

This was one of my guesses, and I have to say that it’s better than any of the alternatives I could come up with. It’s not good markup, though, in my opinion, as it says that semantically, a paragraph is sort of a block-level superclass, a do-it-all and one that you must use if you need that introduction.

But then, why limit yourself to lists? Why aren’t notes tagged like that? Or definition lists, or images, or tables? Think about it. Doesn’t this feel just a little bit like a cop-out to you? It does to me. It feels like the author realised that he needed that wrapper but there was nothing he could cling to, other than this construction.

I’m not saying that my way is the only way (obviously it’s not) but this bothers me because it muddies the semantic waters.

http://mag.ma/andrew/617364

Those familiar with my old schemas and DTDs will now probably raise an eyebrow, but I have finally succumbed to the lure of footnotes in the inline content model of my all-purpose personal DTD.

What finally convinced me was my need to create multiple references to a single note that, while interrupting the text flow and thus unwelcome in the text itself, was too short to place in a section of its own. There was no logical way to semantically identify that note in a form or in a place that would allow me to reference it from several different points in my text. Footnotes (and footnote references) solve that problem very neatly, and the allow me to present my footnotes as end notes using a different stylesheet.

Coffee, as you all know, is the lifeblood of any office. Well, our coffee machine is dead and while I would have liked to say that it didn’t suffer, the trail of dried-up coffee along the floor speaks the opposite.

Expect a slow day after the Eastern Holidays, here.

Title says it all.

There will be a one-day symposium on the theme XML for the Long Haul, right before the Balisage conference in Montréal this year. I’ve thought about this, lately.

First of all, isn’t this what XML is about? The ability for information to survive a proprietary method of conserving it? The means to make it happen, regardless of what happens to your software? I’ve preached about this for a long time for my customers, listeners, and those who just couldn’t get away. If a disaster happened to your software, if it was somehow wiped out in spite of your best efforts, my point was that it would only take a few days to build something that would parse most of the information in an XML file. Maybe another few days to produce output from it, but provided that you spoke the written language and the structure was done by someone who had at least a basic idea of what XML (and SGML; this isn’t new) was about, it wouldn’t take more than a few days at most to see what that lost information was about.

Second, my points re the first, above, pretty much summarise my views here, but I really mean it: This is what XML is about.

But is it really that simple? Is markup really that descriptive? Well, not always. There’s plenty of markup out there that is obscure and hard to read. For example, is a namespace going to make your leftover instances easier to read? Are your element type names descriptive? What about your attributes? Do you include comments or annotations with your schema? Do you include wrappers that contain groups of element types in a semantically meaningful way? Does your group include everything required for that group to be complete? Have a look at one of your instances with fresh eyes, see if it makes sense. Does one type of information relate to another? How would you format this lost instance, if you had just come across it? If it had been a thousand years and you could understand the language but not the culture, would you understand the meaning of the information? Could you print it and explain what went on then?

Don’t laugh. Pretend that you really are viewing your structures from the outside. Pretend that you don’t have the schema at hand. Pretend that you don’t know the semantics, even though you can understand the contents. Pretend that you really are studying the information as an outsider. Does it all make sense?

I think this is a worthwhile reality check. I think that we all should ask this of the schemas we create, every time we do an information analysis. Are our schemas understandable? Are they legible?

I would really like to be in Montréal in August this year. I think it’s important.

The film festival is past the halfway mark now. And yes, I’m counting the hours.

Norman Walsh is the XML Rock Star. Who said being an XML guy is not glamorous?

Had reason to revisit Not the SGML FAQ.

It’s still the funniest piece I’ve read on SGML or XML.

Title says it all.