I’ve been reflecting some more on Adobe e-booker Bill McCoy’s post extolling the use of Flash in e-books. Check out his defense of the post. Not very convincing. It’s more of an attack on OpenReader than a cogent justification of Flashy e-books. I’ve replied.
Very possibly we’re seeing a Chinese box or Matryoshka doll strategy from Adobe. The metaphor isn’t perfect, but certainly comes close. My continued fear is that Adobe wants to use formats within formats–in other words, add-on formats like Flash’s–to prop up the Tower of eBabel. If Bill wants to allay such concerns, then he would do well to ask the IDPF to move standards work to an OASIS technical committee.
Paying dearly
Unless we watch Adobe and IDPF very closely, e-book publishers may pay dearly for creation tools, DRM, you name it, and it could take many extra years for wrinkles like deep interbook linking to become common realities. Not to mention the added barriers for the disabled, Oh, and we also need to keep up with Microsoft–which is AWOL as a truly key participant in the IDPF standards efforts. What does that tell you about the IDPF and the proprietary formatters?
The current IDPF standards effort means interoperability not! Instead they increase the chances of Microsoft doing to e-book formats in the end what it did to word-processing ones.
If Adobe is smart, it will leave the IDPF frog pond for the OASIS standards mainstream and gain the credibility it is now missing. I’d be more likely to trust Adobe on Flash and other matters if the standards process were more rigorous than it is now at the IDPF.
I found Bill’s Flash blog quite interesting. However, there was a general lack of discussion of what I deem three important general requirements:
Accessibility
Interactivity — the gamut of intra- and inter-publication linking, annotation, interfacing with social and community applications, etc. As my crystal ball indicates, this is the future in the consumer use of digital publications.
Very long-term library and archival access and repurposing — an important issue to our cultural heritage.
What appeals to me about XML-based solutions is that, when properly formulated, they address the three items above. What concerns me about Flash, when used for publications which contain a significant amount of text, is that it is not XML-based (at least that’s what I surmise, but I may be wrong.)
So I hope that Bill, in a followup article in his blog, will address these topics.
Also, isn’t animated SVG an alternative to Flash? Or is it not possible to do some things with SVG that can be done with Flash? If SVG is an alternative, why not begin the process to move the Flash format over to a SVG framework?
Inter-publication “deep linking” and annotation has been brought up a number of times, including recently in the post at http://newteleread.com/wordpress/blog/?p=5067 at “Interactivity, annotation and inter-publication linking”. I’d like to point out that that problem can be and often is solved without having to do very deep format engineering.
The key idea, which isn’t original with me, is just to identify the content in the target document you’re referring to (if necessary, the nth occurrence of the content), and then let the application take care of finding that spot and doing the appropriate routing, annotation-anchoring, or whataver. No need to get all complex with assigning internal identifiers unless you want to; the addressing by content works just as well with plain text as with more complex formats. (You’ll notice I used it in the previous paragraph, to refer to a specific spot in Jon Noring’s post. Of course, in a reader application, the program could automatically construct an appropriate content cue just by my pointing to or clicking on the content, so I wouldn’t have to manually write out the phrase to search for.)
For this to work, two things are required:
— One, that the document doesn’t change much after you refer to it, since in those cases the inferred “destination” might become invalid. But then, books and other literary works are expected to stay pretty much the same once published, and if they do change, there are other issues with the validity of the citation anyway (like the fact that the citer was looking at a different document than the reader is.)
— Two, that the application (or the reader) is free to analyze and interpret the target document, in order to find and point to the appropriate points in the document. This should be feasible as long as the format [a] is openly defined, [b] is well-supported in reader software, and [c] does not have DRM getting in the way of the application. It looks like OpenReader and the IDPF are both aiming for [a] and [b]; what will happen in terms of [c] remains to be seen.
It is intriguing to reference a spot in a textual publication using the text itself. It is even possible, provided the text string is unique enough, to not even require identifiers of any kind — it’d be almost like doing a Google search on some document space.
Obviously there are problems with this approach as there are with every approach. Standardization still appears necessary so the references are machine processible to something the search engine can use.
In the audio and video world, where there is no underlying text, pointing to particular spots or ranges within the media cannot use this approach, at least for the foreseeable future (there’s no text to latch onto.) One still has to rely on fixed references such as timestamps, and a unique identifier for the digital object.
One advantage of XML is the markup acts as reference points in the text document that can be directly addressed by id or by tag counting (XPointer schemes), and it is already pretty much standardized. Plain text is more problematic since it is not marked-up. With plain text, unchangeability of the document is more critical, while with XML one may make significant changes to the text, yet by keeping the markup pretty much intact, have some guarantee that old links will still properly work.
All in all, this topic is definitely complex, yet it is critical to reasonably resolve in our interactive future, and do so in standardized ways.
Tag-based references work if the original document has ids or tags in the right places. Not always true, even for XHTML. And there’s the issue of span-linking (creating arbitrary spans in the target document to link to). On the other hand, the Phelps/Wilenskey “Robust Hyperlinks” do pretty well in a variety of circumstances. I (again) recommend reading the paper for a discussion of these issues.
The ID structure of XML are nice, but the problem with *relying* on them as your main linking and annotation mechanism is that you’re stuck with the IDs that the author saw fit to include in their document, even though you might well want to link somewhere that’s not specially marked. (You have some more freedom when you go to XPointers, but that has many of the characteristics and limitations of content-based links, including fragility when a document is changed. Plus, things get messy when you want to link to arbitrary text in the middle of an XML element, where, e.g., DOM and XPointer have different ideas about how to count characters.)
The nice think about content-based references is that they don’t depend either on the author’s cooperation *or the target format’s cooperation* (as long as the format has the two basic characteristics I described in my earlier comment). That is, you don’t have to wait for the ideal next-generation ebook formats to start making deep links and annotations to ebooks; you can apply them to “legacy” documents after the fact, as well as to new formats. Now, if you want to author new ebooks that include embedded links *from* them, then yes, you have to come up with some standard, but that can be done with a fairly simple notation that could be applied in a variety of formats, XML-based or not.
It works with audio and video too — e.g. timestamps are essentially inferred from the content, not explicitly embedded in the format, as far as I know. I’m told that’s one way that viewers who like that sort of thing could play back “clean” edits of films on DVD; use annotations saying things like “at 23:50.04 into the feature, mute the audio for 0:00.40; at 29:34.08, skip ahead 00:13.24”, etc. These reference points aren’t explicitly encoded in the film itself but can be inferred from the content. The main barriers to these sorts of things has been not in the underlying video formats, but in the DRM and legal regimes around them. (I recall companies like CleanFlicks getting sued by Hollywood types, though I don’t know offhand what the eventual outcome was.)
Regarding Bill’s comment above, it is possible to address a particular element in an XHTML or other XML document, which does not have an id value, using the XPointer element() scheme. And for those who want to address right down to particular text, there’s the Xpointer xpointer() scheme.
But, obviously, if the XML document is edited, addresses using these schemes may break — addresses using xpointer() are especially vulnerable.
The idea of addressing by pointing to actual words in content in the document is certainly intriguing (note that the xpointer() scheme has, in a rudimentary way, some of this capability.) This was brought up at the Reading 2.0 conference which John Mark Ockerbloom and I attended. No doubt the work cited by Bill (a 2000 paper) figured into that discussion by some roundabout way.
This whole discussion would not be an issue if, once a publication is finalized (such as a book), it is never edited or updated again — it is fixed forever. But the reality is that digital documents and publications may morph over time because it is so easy to do. I find that I often do minor edits (fixing typos) to both blog articles and comments after they’ve been posted. And certain types of publications, such as education textbooks, need to be continually updated whether they are paper or digital. History textbooks is a notable example.
The paper Bill cites lists some downsides to building addresses based on content words. Obviously, if a document is sufficiently edited so some words in an address disappear from the text, then the addresses will be broken. Word search algorithms can look for documents which partially fulfill a given list of words to search, so that may help locate one or more documents that might be the right one — a human then has to take it from there to determine if any of the found documents is a “hit’, just as one must do when doing a Google search.
Of course, one would prefer a perfect hit everytime, so when I click on a link in an e-book referencing another e-book, that the target e-book will be immediately opened to the spot of interest (should I own or have access to the e-book), rather than generating a list of possible candidate publications. In addition, if the target e-book is a newer edition than what was used to build the address, that I may open up the newer edition and get to the right spot.
This is the goal, but not always possible no matter what system is used to build addressing. There is definitely a need for publication authors to follow certain practices when it is their goal that links to an older edition of a publication, like an e-book, will still work for the newer edition. If the underlying documents are XML, it is easier for the publication author to achieve this goal provided they added an id to every noteworthy element in the first edition, and then did their best to preserve the id values at the appropriate locations for subsequent editions. Unfortunately, many publication authors will not have such foresight no matter how much one cajoles them to implement this practice. Such is life.