xml-dev - Re: eBook Publishing DTD -- Preconceptual musings

[Jon Noring <noring@netcom.com>]

Jerome McDonough wrote:
>Jon Noring wrote:

>>As I continue to explore and study the needs of the upcoming e-book
>>revolution, I have concluded that developing a basic, general, fairly
>>compact, structurally-oriented e-book publishing DTD makes a lot of sense.
>>If designed right, it should be able to admirably structure for
>>presentation, say, 80-90% of all future e-books (most of which will have
>>simpler layouts), the remaining fraction needing a "plug-in" DTD module to
>>augment the basic DTD, or to use a different DTD.

>Given that a fair number of people within the e-book publishing industry
>already sweated out what they thought was a decent, standard DTD for general
>publishing purposes in the Open eBook initiative, I'm not sure how much
>support you could draw for this idea.  My impression from speaking with
>e-book publishers at the NIST-sponsored e-book event last Fall was that
>those who were interested in using XML were far more concerned about trying 
>to prevent Adobe from making PDF a defacto standard than they were about any
>deficiencies in the Open eBook DTDs.  Getting publishers to consider another
>DTD would involve demonstrating either 1. absolutely clear and saleable
>benefits to consumers in a mass market (that is, why do I need something
>more advanced than Open eBook to sell John Grisham novels online), or 2. a
>clear cost savings in the publication process.  Morever, these benefits
>would have to be clear enough to persuade publishers to revisit the issue of
>what a standard DTD for e-book publishing should look like.

You bring up good points.  I will be discussing them below.


>You could probably demonstrate the need for a more refined, structurally-
>oriented DTD for publishing for particular niche markets, but at this point,
>the e-book people are far more concerned with achieving a sufficiently large
>market to be profitable.  Niche appeal, as far as I can tell, isn't on
>anyone's radar at this point.
>
>That being said, the Open eBook initiative appears to have a continuing life
>in the form of the Open Electronic Book Forum (http://www.openebook.org), and
>from their recent press announcements it sounds like they want to continue
>standards work for electronic books.  My suspicion is that getting everyone
>to agree on rights management standards is probably at the top of publishers'
>list of things to accomplish, but you never know, they might be interested
>in the idea of a more sophisticated DTD or schema for e-books.  You might
>consider contacting them to see if there's interest in pursuing this.

Well, let me say that I am quite familiar with the OEB effort.  I served as
one of Exemplary Technologies representatives to the OEB Authoring effort,
attending the San Diego "writer's party" (mainly as an observer at the
time) where a lot got done.  My associate at Yomu, Ben Trafford, is on the
OEB Board of Directors, and I recently founded a mailing list to discuss
extensible OEB.  If you refer to the OEB Publishing Specification, it does
allow extending the default OEB DTD element set (based on HTML 4.0), as well
as using a new DTD.  For example, one can use much of the TEI element set,
and still have an OEB-conformant document -- although there are not yet any
OEB-conforming reading systems that can render such a document.  (IE5 of
course can render an XML document with a style sheet, but it has a few little
peculiarities where an OEB-conforming XML document has to be slightly edited
to make it display in IE5 -- I hope Microsoft in the upcoming IE5.5 will
do the small changes to make it display an OEB-conforming XML document.)

Well, enough name dropping.

To answer your points.  Let me start off by saying that a lot of compromise
went into the basic OEB 1.0 DTD, and it was settled to stick with a subset
of HTML 4.0 for simplicity sake, so as not to overly burden the existing
e-book reader and publishing efforts which revolved around HTML (e.g.,
SoftBook and RocketBook).  It was clearly seen that separating structure
from presentation was an important goal, so HTML elements that are
presentationally based were deprecated, with recommendations of moving all
presentation to the style sheets.  A subset of CSS1/CSS2 is supported (it
is quite limited, though, and I hope future OEB effort will go into
supporting the full CSS1/CSS2 spec, and/or fully supporting XSL).

As I mentioned above, another thing added to the specification was
extensibility, a very powerful mechanism.

Your points are well-taken.  However, I do know that many at the OEB Authoring
group were and still are interested in going the next step in OEB 2.0, to
possibly specify a new structurally-based DTD.  It is thought that this DTD
would not replace the current DTD, but simply be a second one -- sort of a
OEB-full and OEB-lite approach.  And among several e-book publishers I keep
in touch with, there is an interest in the standard DTD as I've discussed
since it may make authoring/document layout easier, allow the rise of simple
authoring tools where WYSIWYG is not important, and allow swappable style
sheets to be shared industry-wide.  This could be done in the present OEB
spec (without extensibility), but it gets messy since div/span elements will
have to be liberally used.  At that point it's better to bite the bullet
and go with something more powerful and oriented towards the structure of
e-books rather than the different paradigm of displaying Web pages which HTML
is oriented towards.

Another matter is one of time.  It takes time to develop a new specification,
so the planning for 2-3 years down the road starts now, thus the impetus to
start this effort now.

Another matter is OEB itself.  You are right that OEB will likely focus their
efforts on DRM (digital rights management) and simply promoting what we have
now.  And that is good.  So my proposed effort would, for the time being, be
outside of OEB, and once it gets to a draft stage, we can certainly present
OEB with the draft and see if they'd be interested in sponsoring it or not.
Even if they don't, the current OEB spec, with its extensibility, will allow
the use of the DTD we build.  The DTD can certainly be made "OEB friendly",
and to get feedback from OEB people during its formulation.

I could go on, but let me say there is interest in a new DTD as I outlined,
that it does make sense (it would take a lot of words to explain why --
hopefully Frank Boumphrey can give his perspective here), that OEB can
certainly be approached with a draft and a proposal and there are people
inside OEB who will privately support this activity, possibly even our
friends up in Redmond (don't know really, but plausible for reasons I won't
get into here.)

Thanks for your feedback.

Jon Noring
Yomu


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************