The case for HTML in OpenReader

Roger Sperberg’s latest TeleRead article, the “Case Against HTML in OpenReader”, is also a “case against HTML in OEBPS” and a “case against HTML in web documents”, etc. So, in actuality, the general issue is not really specific to OpenReader, but also applies to OEBPS.

I interpret from his prior articles that Roger would like to see OpenReader make even bigger changes, and sooner rather than later. So would I! I agree in principle with a lot of what Roger says regarding where we want to end up — the Vision. In addition, his latest article gives a simple-to-understand exposition on the problems with the HTML vocabulary, as well as providing a wonderful tutorial on the advantages of specifying content semantics. Well done! But I’d disagree with him on the issue of inclusion of HTML, and will give the details here.

Why HTML is a viable, but not the best, e-book document format

I’ve written many times (mostly to The eBook Community) that HTML is actually a pretty poor vocabulary to represent may types of publications such as books, so I’m not unfamiliar with Roger’s arguments. But, despite its limitations, HTML does work for presentation purposes — most publishers today will find it more than sufficient for representing digital publications for presentation purposes. So it is a good starting point upon which to evolve the OpenReader format specification. I don’t see a problem with starting out using a carefully constrained, structurally- and semantically-focused subset of XHTML for OpenReader Basic Content Documents.

With my appreciation for Roger’s continuing contributions to this discussion (which is sorely needed — his articles have nudged me to write more about OpenReader), let me delve into some specific topics related to getting from here to there:

Getting to vocabulary agnosticism and specialized markup vocabularies

As I understand it, Roger’s basic view is that the OpenReader Publication Format should, as soon as possible — if not immediately — allow publishers to use pretty much any validated markup vocabulary [note] for the XML-conforming content documents.

A related argument I think Roger is giving is that if OpenReader does not move as fast as suggested, it will not meet publisher’s immediate needs, and therefore will fail. I don’t agree with this second argument (as I state it), and won’t discuss it any further in this article, but may in a future article. (Of course, this means OEBPS will likewise fail if used the same way OpenReader will be used. Yet many publishers and content conversion houses we’ve talked with are familiar with OEBPS and have no difficulty in using its XHTML for representing their content — the extension to OpenReader is obvious.)

Let’s get down to brass tacks and discuss what the format spec must handle to reach the ultimate goal, which Roger and I both support, and what that means for the immediate future. For starters:

• XLink

  Roger does not delve into the gory details of how to handle, in any XML content document, hypertext linking, image, and multimedia object embedding.

  For supporting publisher-supplied markup vocabularies, this must be accomplished using a standardized, vocabulary-independent method. W3C’s XLink specification is just what the Doctor ordered.

  Supporting XLink now, or some subset of it, introduces a host of issues, including implementation timing, user agent support, accessibility, etc., all of which have to be carefully considered.

  Nevertheless, some XLink support in the OpenReader format will be implemented very soon, so it does appear to meet Roger’s timeframe.

• Specialized Markers

  The publishing community has expressed substantial interest in machine-processable “mile markers” and other similar specialized markers which they want to use in publications. The markers would be used, for example, to designate page markers in a parallel paper edition.

  Like XLink support, these mile markers must be based in a standardized way so they may be used in any XML document. We plan to accomplish this using the OpenReader namespace since we have not found anything else out there we could embrace that will work properly. We are now putting the finishing touches on designing this marker vocabulary — it requires some changes to the Binder as well since everything in the OpenReader format (as it is in OEBPS) is highly interlinked.

• Specialized Vocabularies

  I also agree with Roger that it is a Good Thing™ to support special purpose markup vocabularies such as SVG, MathML, etc., etc.

  And this is a goal of the OpenReader Publication Format. So we are in alignment with Roger’s recommendation.

  But doing this introduces a “chicken-egg” dilemma that requires a careful, and probably staged approach. Overwhelm user agent developers with too much too quickly, and they will ignore supporting these vocabularies — if fallbacks are provided, they will use those instead (which we don’t really want); if fallbacks are not provided, they will simply not do anything with the specialized markup (which we don’t really want.) Publishers will be pissed since their markup is not being rendered as they expect — in plain English, it does not lead to warm fuzzies.

  What is indicated here is a careful and methodical addition, starting with SVG (or some profile of SVG), followed by MathML, and later by others as needs demand.

• Accessibility

  As noted before, the accessibility community is really scared of allowing content documents to use a wide latitude of “custom” markup vocabularies. And with good reason.

  Even if someone comes up with a workable solution that meets the accessibility community requirements (and I believe it is possible), embracing the solution needs to involve the accessibility community. This takes time and a lot of discussion to come up with a requirements list and to fully understand the various nuances of the issue. One cannot solve a problem unless one completely understands it.

  We are not there yet. For this reason alone, we cannot, at this time, implement custom vocabulary support in OpenReader. This, in turn, requires us to support some content document vocabulary, and we chose a carefully-selected subset of XHTML 1.1 which is compatible with OEBPS 1.2, forward looking towards XHTML 2.0, and other requirements. But we want to, and plan to in the future, support publisher-defined markup vocabularies, as well as other standardized document vocabularies. So, again, we are in alignment with Roger, but maybe not in the timeframe he’d prefer.

  Also note that the solution has to be implemented by user agents for the visually and reading impaired. If the solution requires a lot of code development (such as to implement language-dependent artifical intelligence algorithms to interpret the meaning of tags), this greatly increases their cost and complexity, and inhibits the embracement of OpenReader by the accessibility community. The accessibility community does not want this, for obvious reasons.

  To ignore accessibility is not an option. We are committed to accessibility not only for moral reasons, but because it benefits everyone for reasons best left for a future article. And it is important to get the accessibility community involved before making any decisions which greatly impact upon them. Vocabulary agnosticism is one that fits this category. We continue to consult with the accessibility community leaders and techies.

The tortoise and the hare

Building the OpenReader format reminds me a lot of the Æsop fable Tortoise and the Hare. Here, OpenReader is the tortoise, albeit on steroids. We want to move fast, and are moving fast, but not too fast.

I like Roger’s vision. I share it. But, like any vision, one has to work back from the future to the present, and determine the best road to take to get from here to there. In the case of OpenReader we have to factor where everyone interested in the format is at present, the requirements of the accessibility community, special considerings for user agent developers, etc. One cannot do B before A.

Technical Note: For those not familiar with the phrase “markup vocabulary” as used in this article, it refers to a particular set of elements and attributes used to markup the text, along with restrictions. For example, HTML is a markup vocabulary, since it specifies a set of elements, such as <p>, <img>, <em>, etc., along with restrictions on how and where they may appear in the document. The vocabulary and restrictions may be codified in a machine-readable, “validatable” manner using what’s called a “DTD” or alternatively a “schema”. But there’s no universal rule that says marked-up text documents must use the HTML vocabulary.

Note, too, that XML is not a markup vocabulary, but a set of rules describing how to apply a markup vocabulary to a text document. Thus, XHTML is an HTML document which conforms with the rules of XML. Oftentimes, in some contexts, the phrase “XML document” refers to a document using some vocabulary other than HTML, but this tends to only perpetuate the confusion when people try to compare XML with HTML — it’s really like comparing apples and oranges.

By the way, I apologize to Roger for previously using the term “roll your own tags.” I did not use that phrase to disparage Roger’s previous article. I’ve heard that phrase used by quite a few XML wonks in a neutral or positive way to describe creating one’s own vocabulary rather than using some standardized one, like HTML. We XML document wonks do have a sense of humor — occasionally. <laugh/>