My heart quickened when I first read about the new Open Content Alliance. Brewster Kahle, founder of the valuable Internet Archive and the main force behind the Yahoo-backed alliance, told CNET: “If we get this right so enough people want to participate in droves, we can have an interoperable, circulating library that is not only searchable on Yahoo but other search engines and downloadable on handhelds, even iPods.”
Well put, Brewster. But just what do you mean by “interoperable?” Will the OCA, Yahoo and others encourage the creation of a common e-book format and an end to the Tower of eBabel? Will the OCA take a stand in favor of an XML/CSSish approach to allow maximum flexibility for the worlds of education and research? How much does the OCA care about the very most powerful forms of searching? Or the most sophisticated kinds of collaboration among authors? And what about the issue of reflowable text that can display well on cellphones, handhelds and, yes, iPods? If Adobe, a major sponsor, dominates the format show at the OCA, this will not be the best news for the open standards movement within e-bookdom.
Needed: More strategic thinking at OCA
Certainly the OCA should accept Adobe-formatted documents, but it would also do well to think more strategically and work toward a gracefully evolving open-standards format. Why dumb down the OCA from the very start? Shouldn’t researchers and, yes, ordinary users, enjoy the benefits of an XML/CSSish approach of the kind that appeals to Professor Terje Hillesund.
If nothing else, an open-standard format would reduce the possibility of the world being held captive to one big corporation, Adobe. Do we really want to create another Microsoft to which so much of the planet is beholden? Even the existing Microsoft feels compelled to include an Adobe-format “save as” in the forthcoming update of the Word program. What will this mean commercially? Just what assurances do we have that Adobe won’t gouge for format upgrades and Reader-related DRM? Or in the future prevent others from creating reader software compatible with the latest format? And what about the hardware factor? Adobe isn’t the best company in the cosmos at keeping its formats up to date for various machines, as users of the Pocket PC can testify.
Unless the Open Content Alliance takes appropriate precautions, Adobe will mainly be using the OCA as a marketing tool. It will exploit Brewster and the appeal of public domain books as a way to lock up the market. Yes, I know that Adobe has good motives, too, but methinks that commercial ambitions count just like altruistic ones–in fact, probably much more.
Fixing Principle Four
So what’s the solution for the OCA? Well, Brewster and friends could start with a modification of Principle Four of the OCA as spelled out on its Web site. Four now reads: “The OCA will offer collection and item-level metadata of its hosted collections in a variety of formats.” A new version could remove the ambiguities and read simply: “OCA will strive to offer collections with content and all levels of metadata in a variety of formats.” A second sentence could read, “At the same time OCA will support the concept of the development of a powerful XML/CSS-based format that can be used in a wide variety of applications.”
Does that mean OpenReader, in which I’m involved? Not necessarily. The question can be decided by consensus. If nothing else, however, OpenReader illustrates the great potential of an XML/CSSish approach building on the existing standards from the Open eBook Forum, now known as the International Digital Publishing Forum. Those standards arose from the hard work not only from the private sector but also from Victor McCrary, at the time the main e-book evangelist of the National Institute of Standards and Technology. Does OCA really want to toss out all those efforts to please the sugar daddies at Adobe?
Making OCA publisher-friendly–beyond copyright
Granted, Adobe in many ways is a fine company, and it deserves to play an important role in the evolution of e-books. But U.S. law encourages it to maximize the rate of return for the shareholders, as opposed to doing what’s right for e-bookdom. And speaking of shareholders and the law and profits, how about other companies–publishers? Do they really want to be beholden to one giant company that, on whim, will be able to raise fees for DRM and other services? Then F factor, then, isn’t just an issue for consumers and researchers. Imagine an Adobe-only future, or near-Adobe-only one—especially when a Bush-shaped Supreme Court may weaken anti-trust laws? Even now some publishers may pay 10 percent or more of a book’s price for format and DRM services from Microsoft. Is this best for an industry notorious for low margins?
Simply put, if the OCA, Brewster and Yahoo want to be publisher-friendly, in ways beyond copyright, they need to show it–first by the rewrite of Principle Four, second by their actual actions.
Detail: Yes, you read that right–I’m suggesting many formats for OCA, despite my loathing of the Tower of eBabel. The reason is simple. Fairness. Let the marketplace on its own settle on a common format.
To Bill McCoy, Adobe’s OCA rep: I still have hope for Adobe. Why not work with the entire e-book community to phase in an open XML/CSSish format? You could ease the transition by way of software that also read legacy stuff. By embracing an open format, you could lessen the fear of an Adobe monopoly. Hey, you know what it’s like to compete against Brand M and its lawyers.
“a common e-book format” is a great ideal, but
there’s no reason it must be based on xml/css…
i’ve developed a format that works quite well,
and isn’t nearly as difficult as its .xml cousins.
it’s interesting that — when you fear x.m.l. will
be written out of the picture by fiat — then you
suddenly advocate a variety of different formats
so “the marketplace on its own” can “settle on”
a common format. but if _you_ could dictate,
you’d have no hesitation in dictating x.m.l. why?
-bowerbird
Bowerbird –
I think I can answer that one since I have been working with XML formatted documents for nearly three years and have struggled to convert PDF titles into XML.
XML with CSS is versatile and can be transformed into other documentation formats including HTML and PDF. Style sheets allow the publisher/user to modify the output to meet customer needs.
PDF format is a typeset paginated view designed to replicate the printed page and therefore describes layout, not the meaning of the content. (ie: title, chapter, headers).
The highly structured XML format allows for customization and advanced feature sets often requested by academic, business, research, and serious literary communities. The link to Professor Terje Hillesund’s article in David’s post was very revealing.
The biggest challenge facing XML is that there are no widely accepted applications for content display and creation. Creating/coverting content is time consuming and difficult and there are limited ways to view output. I view XML as a transition format – allowing you to render the output any way you desire. That is why “XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere.” (WC3) OSoft, working in conjunction with OpenReader.org, seeks to change that:
– The next major release of the ThoutReader will support and personify the OpenReader standard.
– OpenReader.org is completing their DTD and several universities have offered to write plug-ins for Open Office, Microsoft Word, HTML, and other document formats.
– It is our goal to eventually have creation tools completely embedded within the reader since they are so closely aligned. This makes it easy to view output while it is being created.
– Our ultimate goal is to be able to read other documentation formats natively by converting content on the fly within the reader.
Sadly (for the publishing industry), I believe David Rothman is correct. Publishers need to fight for open standards. XML is non-proprietary, vendor neutral, and is supported by WC3 (http://www.w3.org/XML/).
oops! i wrote most of my reply midway through reading yours, mark,
and i didn’t remember that you’re the osoft programmer. so you can
“ignore” what i’ve said below, you don’t want to be “distracted” from
your work. as you can see, i’m the disloyal opposition, and i wish you
the best of luck in the friendly little competition we’ll be having… :+)
my stake is a dirt-simple format, easy creation, and powerful tools…
you’ve got a complex format, and difficult creation too, so i would say
you’re going to have to make some very powerful tools to compensate.
in the end, however it turns out, let’s hope electronic-books win… :+)
——————————————————-
mark said:
> XML with CSS is versatile
it is versatile. it’s also difficult.
ordinary people don’t like difficult.
> and can be transformed into other
> documentation formats including HTML and PDF.
my format, which is simple, can be converted too.
i’ve got a sample version of “alice in wonderland” up.
the “master format” is a fairly ordinary text-file:
> http://snowy.arsc.alaska.edu/bowerbird/alice01/alice01/alice01.zml
here it is transformed into an .html file:
> http://snowy.arsc.alaska.edu/bowerbird/alice01/alice01/alice01.html
and here it is as a pdf:
> http://snowy.arsc.alaska.edu/bowerbird/alice01/alice01/alice01.pdf
mind you, i don’t think anyone’s going to _want_ these other formats,
because they can read the .zml (zen markup language) file directly in my
zml-viewer-app, which gives more capability than acrobat or a browser.
but if someone _does_ want to do such a conversion, it will be possible.
> Style sheets allow the publisher/user to modify the output to meet customer needs.
in my viewer-program, the user sets the options the way they want them.
whatever options are in effect are used to create the .pdf or the .html file.
so creation is an organic thing growing out of the selection of preferences,
and is as easy as clicking a button to select the particular format they want.
but again, why use some other format when they one you’ve got is better?
> The biggest challenge facing XML is that
> there are no widely accepted applications
that’s one…
> for content display
that’s two…
> and creation.
and that’s three…
> Creating/coverting content is
> time consuming
that’s three-a.
> and difficult
that’s three-b.
> and there are limited ways to view output
and that’s two-a.
so i see a triple-whammy of “challenges”…
on the other hand, my format is:
1. so simple you don’t even need to codify it in a bureaucratic standard.
(i literally pitched it as something a fourth-grader could easily understand.)
2. already supported with a free (beer) cross-platform viewer-program.
(and since the format is so simple, anyone could write another viewer.)
3. able to be created in a text-editor, and that’s not a line of hype either.
(look at the sample “alice” .zml file; you’ll see you could do it in “notepad”.)
> I view XML as a transition format –
> allowing you to render the output any way you desire.
why keep “a transition format” around?
make the plain-text your “master” and
render it the way you want, converting
to another format only if you need one.
meanwhile, you’ve always got plain-text.
one of the easiest formats to interact with.
one for which lots of tools already exist.
who needs the verbose labeling of x.m.l.
when data is as plain as nose on face?
> – It is our goal to eventually have
> creation tools completely embedded within the reader
> since they are so closely aligned. This makes it
> easy to view output while it is being created.
you should read the response i wrote to
jon noring’s “white-paper” he published
on ebookweb a few years back. you’ll see
that i was advocating a good part of your
agenda now way back then. and still am.
i incorporated it into my own programming,
and my “zen markup language” philosophy. :+)
at any rate, best of luck on your effort, mark!
i’ll see ya in the time-tests and
the feature-comparison tables
of the computer mag reviews…
-bowerbird
in the comment i made above, i just pasted those u.r.l.’s in.
the software went and automatically turned them into links.
that’s cool. easy for the writer. and powerful for the reader.
that’s a good example of “z.m.l.” — “zen markup language”.
why make the user jump through hoops to declare a link?
no good reason. just make the link automatically.
just in case you needed an example… ;+)
-bowerbird
p.s. by the way, the .html and .pdf versions of alice
that i linked to above are just _first-drafts_ of the
conversion routines, so if you have any feedback,
please do feel free to send them to me! :+)
Bowerbird –
In your response above, you wrote the word “my” eight times!
“my reply”
“my stake”
“my format”
“my zml-viewer-app”
“my viewer-program”
“my format”
“my own programming”
“my zen markup language”
I believe there are three kinds of people in the world. Those who “make things happen”, those who “watch things happen”, and those who “wonder what happened”. My point?? If YOU have a documentation format that could and/or should be the industry standard for all of the reasons you describe (and there appear to be many), then I suggest you get involved with http://www.openreader.org or create your own foundation and push for adoption of your format.
The alternative is to incorporate the best qualities of ZML into established standards.
OSoft would welcome the opportunity to work with you on this endeavor and possibly develop a ZML plug-in for our reader. You have some great ideas and are passionate about the subject. We would rather have you in the game than being a “Monday morning quarterback”.
BTW: Thanks for your nice public notes comment in My Antonia. You haven’t seen anything yet!
Mark Carey
mark said:
> If YOU have a documentation format that
> could and/or should be the industry standard
> for all of the reasons you describe
> (and there appear to be many), then
> I suggest you get involved with http://www.openreader.org or
> create your own foundation and push for adoption of your format.
are those my only two choices? :+)
i don’t think a working relationship with openreader.org
is in the cards for me.
and i have no interest in “creating my own foundation”
or in “pushing for adoption of my format”. that kind of
focus would distract me from pursuing the next idea…
i wish only to expose my idea, and show it works,
with real-life programs. if society wants it, fine.
if not, fine.
i’m just revealing the “simple” option.
it makes no difference to me whether
people choose to exercise this option,
as long as they know that it is an option.
but you can rest assured that i am
no “monday morning quarterback”.
i’ve been closely examining e-books
— inside and out — for 25 years now.
if you want to put a z.m.l. “plug-in”
in any of your programs, that’s fine.
the format is simple enough that you
will have no problem implementing it,
but if you do have any questions, ask… :+)
best of luck in your programming!
-bowerbird