Non Standard

Volume 19, Issue 17; 16 Jun 2016

Being a few reflections on twenty years in markup standards.

If you think of standardization as the best that you know today, but which is to be improved tomorrow; you get somewhere.

Henry Ford

I’m a markup geek. I like markup. I abandoned word processors the minute I found ScriptIt’d be interesting to work out what flavor; whatever ran on MUSIC/SP in the mid-eighties.. I was so determined to stay away from word processors that when running Script on the mainframe became irksome, I tried (naively!) to write my own Script processor for the PC. I abandoned Script when I found TEX, TEX when I found SGML, and SGML when XML came along.

I started learning about SGML in the mid-nineties. The earliest record of standards participation that I can find is in the agenda for the June 27-29 Davenport Group meeting in 1994:

Tuesday, June 28

 9:00 - 10:00 Continental Breakfast
10:00 - 12:00 DocBook Issues (see attachment 1)
12:00 -  1:00 Catered Lunch
 1:00 -  3:00 Presentation by O'Reilly & Assoc.
              Lenny Muellner and Norm Walsh
              DocBook -> gtroff Project
 3:00 -  3:30 Break
 3:30 -  4:30 Open Discussion Period (see attachment 2)

The Davenport Group was the consortium that managed DocBook maintenance before SGML Open (which became OASIS). So I’ve been doing markup standards for more than twenty years.

There are lots of reasons to be engaged in the standards process:

  • To achieve interoperability. The whole point of a standard is to make it possible for different systems to interoperate. Some economic environments foster standardization and some don’t.

  • To demonstrate thought leadership. Or to be perceived to be demonstrating it, anyway. Standards participation as a marketing exercise.

  • To influence the outcomes. Ideally, the only goal is to produce the best standard. In practice, corporations want the standard to match their existing implementations and they’ll endeavor to achieve that goal more or less subtly depending on the circumstances.

  • Idealism. Corporations want control. Individuals want freedom. We tell ourselves that interoperability reduces control and increases freedom.

  • To get there first. If you’re working on something that does X and X is being standardized, working on the standard helps you get to standard X first. Even if the standard is being developed in the open, first hand experience in the conversations about the standard can be valuable.

  • Camaraderie. For years, all of my best friends have been folks that I’ve met doing standards. The XML community is absolutely chock full of smart, interesting, wonderful people. Statistically, way over the average, I think. There are few things quite as intellectually enjoyable as getting together with smart folks trying to solve a hard problem.

I’ve done it for all of those reasons at one time or another, mostly at the W3C.

I’m listed as an editor on 31 published documents at the W3CAt one time, that was a lot; I don’t know if it still is.. If you include all the working drafts that lead up to those 31 specifications, the number is closer to 100, almost all of them are about XML. For the bargain price of $495, The Gartner Group will sell you the Hype Cycle for XML Technologies circa 2006. My summary is free: it was a fun ride.

And what did we end up with (in 2016)? Well…

JSON

JSON is clearlyNo. It turns out, it’s not clear at all. not XML, though you’ll find lots of folks who claim it’s better for lots of things. Some of them are right about some things. You have to squint awfully hard to view JSON as markup, but I’ll grant that it is, of a sort. Simpler, by some measures, than XML, but evidently still too complicated.

HTML

It’s the clear winner and still champion of angle bracket markup languages. It’s not XML either. It has an XML serialization but that hardly matters. If you’re going to usefully parse HTML, you’re going to do it with a bespoke parser that turns any sequence of characters into an HTML document. That’s of real value in some environments.

DITA

In the technical documentation space that I’ve cared most about for all these years, DITA appears to be the dominant player today. Marketing muscle and the promise of reduced costs make it an easy sell to managers. It’s also not XML. [Oh! You’re going to get hate mail about that —ed] Like HTML, it has an XML serialization, but that’s a convenience as much as anything else. It absolutely isn’t idiomatic XML. If you don’t believe me, consider the enormously rich, complex, and subtle DITA semantics embodied in Hyperdocument Authoring Link Management Using Git and XQuery in Service of an Abstract Hyperdocument Management Model Applied to DITA Hyperdocuments. Or, more directly, simply consider how the semantics of every DITA element depend on the complicated interpretation of a structured attribute value.

I’m not saying this is bad or unnecessary for the task it’s attempting to solve. I’m just saying a general purpose, vocabulary neutral XML tool isn’t going to provide very reliable insights into a DITA document.

DocBook, JATS, TEI, etc…

Finally, somewhere down in the more-or-less long tail, we come to idiomatic XML vocabularies. Each has a community of users, a potentially enormous corpus of documents, and will survive happily into the future no matter what prognosticators say about the death of XML. They’ll switch to something else when something better comes along, HTML5 with class attributes ain’t [expletive deleted —ed] it.

Standardization gave us parsers, not used for the most widely deployed markup languages; a couple of grammar-based schema languages, a widely implemented one that relatively few people like and a marginally implemented one that most people do; at least one very nice rule-based schema language; several processing languages that really are better than everything else for markup; a pipeline language that’s too little, too late, and too complicated; a standard vocabulary for linking with only minority adoption; a fragment identifier framework; and a transclusion processor. Plus vocabularies of course, and maybe other things I’m forgetting at the moment.

All of the recent standards efforts that I’ve been involved in have been refinements of existing work: very interesting and potentially powerful refinements, but under development by smaller and smaller groups. It took me more months than I am willing to count to find a second implementor for XInclude 1.1, despite the fact that it offers a small, useful, compatible enhancement. Since October of last year, I think the design of a potential XProc 2.0 has become dramatically more interesting, but any efforts to continue its development will have to come to terms with whether or not it is possible to achieve two implementations.

At the end of the day, I have come to accept the unpalatable truth that there are fewer and fewer organizations interested in continued development of XML standards and a tiny minority of overworked volunteers attempting to accomplish them. For several years, I’ve pressed on with the goal of “finishing one or two remaining things,” but I also have to accept is that there will always be “one more thing.” It’s the nature of engineering that there’s always room for improvement.

I just can’t convince myself that it’s the best use of my time anymore and my employer, despite being XML to the core, isn’t really wringing a lot of value out of my efforts either. With sorrow, regret, and angst, I have reached the conclusion that it is time for me to stop.

Standards, that is, not XML.

XML has a long future ahead and I look forward to doing my part to advance the state of the art: teaching and presenting at conferences and workshops, implementing new tools and products, and helping people and organizations leverage XML for real value.

I have some optimism that I can turn the few hours a week that I have of late spent spread too thin across several fronts, fretting and feeling guilty about my failure to complete one or another set of action items, into productive time to work on my own projects, including “JAFPL”: Just Another F…ine Pipeline Language, my own ideas for an XProc successor.

Maybe someday I’ll be persuaded to work on standards again. I really did enjoy it and I really did meet some wonderful folks. Good luck to you all! And see you at Balisage and XML Summer School and beyond. My vacation plans collided with XML London this year, but I’m looking forward to it next year (and XML Prague and XML Amsterdam and all the rest).

Comments

A big loss for W3C and Oasis, I'm sure - but totally understandable.

See you at XMLSS!

—Posted by Tom on 16 Jun 2016 @ 02:45 UTC #

Looking forward to JAFPL.

—Posted by Sean McGrath on 18 Jun 2016 @ 12:54 UTC #