To most people, objects are things you can touch, see, maybe even smell. They have existence on their own. Software developers talk about objects as well. Although they're more abstract, software objects can also be touched- programs can interact with them, and they exist on their own as packages of code and data.
In some recent conversations about books and content containers, I've been hit in the face with the fact that most people in publishing haven't been steeped in Object-Oriented Programming (OOP) the way I once was, and as a result, some of the things I've written about the evolution of the book into digital form have sounded a bit strange to many people. So I've decided to write a bit here about how books are becoming software objects, and why it matters.
Object orientation is a style of programming that models problems as spaces of objects from various classes. The programmer solves problems by manipulating objects; the objects communicate among themselves by passing messages. The messages that objects pass are governed by interfaces; every class of objects is defined by the interfaces it supports. If that doesn't make sense to you, don't worry, I'll have some examples.
Let's think about how we might model the book as a software object. With a physical book, you know how to get the title and name of the author. You open up the book to the title page, and there you find the title, probably the words in the largest type size, and the author's name, probably printed below the title, perhaps with a designator word such as "by".
In the prehistory of programming before OOP, a book program might define data structures containing tables of book titles and author names. The program would look in these tables for the book data. An object-oriented program would instead send the book-object messages saying "what is your name?" and "What person was your author?" An object-oriented approach binds the code and data together, so that objects of the book class know what their title is, how many chapters they have, and what the 20th word of the 32nd paragraph of their 3rd chapter is. The set of messages that an object can respond to defines its class. A programmer knows that any object in the Book class will be able to tell you its title.
Another key concept in object orientation is inheritance. A cookbook is a book and inherits from the Book class the ability to tell you its title. But you expect a Cookbook to have recipes, and you should be able to ask it how many recipes it contains.
The reason I think this is important for non-coders to understand is that very soon, the book industry will become focused on producing lots and lots of these software objects. And I'm not talking about some far-fetched digital utopia.
The third revision of the EPUB standard is very soon to become a reality, and I believe its use will quickly become pervasive in the book industry. It would be a mistake to think of EPUB3 as yet another document format. With the adoption of EPUB3, the book industry will, for the first time ever, have standardized a software object model for the book. This comes along with EPUB3's use of HTML5 as a foundational layer.
An object model became associated with HTML documents very early in its evolution. Called the DOM, or Document Object Model, it was developed by programmers working with HTML documents, and it quickly became the basis for most software that works with HTML documents. With the development of Javascript, HTML documents delivered over the web could bind to code that accesses and manipulates their data via the DOM. It's only with HTML5, however, that the DOM is officially becoming part of the HTML standard.
With HTML5 as its basis, EPUB3 becomes a very capable "container" of content. The whole discussion of how containers limit the ways in which content can interact with consumers becomes completely moot, and a bit silly. EPUB3 binds a complete "API" (application programming interface) onto the content, and provide many mechanisms for the extension of that interface. The "API" and the "container" are one and the same.
If we look at the immense infrastructure that arose around the book as a physical object, from book bags and compact shelving, to printing plants, warehouses, libraries and used bookstores, we can get an inkling of the infrastructure that will grow up around the book as a software object. In the coming weeks, I'll try to write about some of the implications of EPUB3 for the industry as a whole.
In some recent conversations about books and content containers, I've been hit in the face with the fact that most people in publishing haven't been steeped in Object-Oriented Programming (OOP) the way I once was, and as a result, some of the things I've written about the evolution of the book into digital form have sounded a bit strange to many people. So I've decided to write a bit here about how books are becoming software objects, and why it matters.
Object orientation is a style of programming that models problems as spaces of objects from various classes. The programmer solves problems by manipulating objects; the objects communicate among themselves by passing messages. The messages that objects pass are governed by interfaces; every class of objects is defined by the interfaces it supports. If that doesn't make sense to you, don't worry, I'll have some examples.
In the prehistory of programming before OOP, a book program might define data structures containing tables of book titles and author names. The program would look in these tables for the book data. An object-oriented program would instead send the book-object messages saying "what is your name?" and "What person was your author?" An object-oriented approach binds the code and data together, so that objects of the book class know what their title is, how many chapters they have, and what the 20th word of the 32nd paragraph of their 3rd chapter is. The set of messages that an object can respond to defines its class. A programmer knows that any object in the Book class will be able to tell you its title.
Another key concept in object orientation is inheritance. A cookbook is a book and inherits from the Book class the ability to tell you its title. But you expect a Cookbook to have recipes, and you should be able to ask it how many recipes it contains.
The reason I think this is important for non-coders to understand is that very soon, the book industry will become focused on producing lots and lots of these software objects. And I'm not talking about some far-fetched digital utopia.
The third revision of the EPUB standard is very soon to become a reality, and I believe its use will quickly become pervasive in the book industry. It would be a mistake to think of EPUB3 as yet another document format. With the adoption of EPUB3, the book industry will, for the first time ever, have standardized a software object model for the book. This comes along with EPUB3's use of HTML5 as a foundational layer.
An object model became associated with HTML documents very early in its evolution. Called the DOM, or Document Object Model, it was developed by programmers working with HTML documents, and it quickly became the basis for most software that works with HTML documents. With the development of Javascript, HTML documents delivered over the web could bind to code that accesses and manipulates their data via the DOM. It's only with HTML5, however, that the DOM is officially becoming part of the HTML standard.
If we look at the immense infrastructure that arose around the book as a physical object, from book bags and compact shelving, to printing plants, warehouses, libraries and used bookstores, we can get an inkling of the infrastructure that will grow up around the book as a software object. In the coming weeks, I'll try to write about some of the implications of EPUB3 for the industry as a whole.
Posts
Thanks, Eric, for this view of EPUB. I knew it was undergoing a revision, but I didn't know it was one that could be such a fundamental shift. As the worlds of books and programming come closer together, do you think we'll see the introduction of higher-level code libraries (perhaps in an open source form) that will read .epub files and treat them as objects? Is there work happening within IDPF to create a "reference implementation" of such a code library?
ReplyDeletejester, I'd look at Calibre and Bookworm for open source implementations. Also, almost all the reader implementations (including commercial) are based on Webkit, which is Open Source.
ReplyDeleteNice post, Eric. I think you've nailed the content-centric side of this. But there's an 'ecological' implication of OOP that may become relevant to books too.
ReplyDeleteThe original OOP philosophy developed at Xerox PARC in the 70s was also wrapped up in their R&D on peer-to-peer networking. Objects weren't just a means of encapsulating data+methods; the larger picture was a whole distributed network made up of message-passing peers.
We *almost* have something like that P2P architecture with the open Web today, despite the fact that the Web appears very centralized around powerful servers (Google, Facebook, Amazon, etc.). We *almost* have an architecture where book-like objects are queryable and message-able across the whole Internet, in a peer-to-peer fashion, rather than the big centralized tables that a company like Amazon or Bowker is built on.
The difference between the one vision and the other is almost more of attitude and expectation than anything 'technical'.
jmax- a comparison between ISBN and DOI is an exercise left for the reader.
ReplyDelete