[Note to the OpenReader format group: I just posted the following to
the new IDPF OEBPS Working Group of which I'm an invited contributor.
I've been a contributor to all versions of OEBPS. Anyway, you are
welcome to provide feedback, as you see it, on the "out-of-spine"
issue, both supportive and critical of my position. It is relevant to
the OpenReader Publication Framework. Thanks! Jon]


Everyone,

Since the "out-of-spine" feature of the current OEBPS spec is
curiously (and troublingly so) on the slate for discussion at the
Face-To-Face, and because I am unfortunately unable to attend the F2F
in person, I want to start dialogue well in advance on this topic, and
give some of my thoughts on "out-of-spine."

I'll touch upon why it is critical to maintain and to even expand
this feature, rather than remove it, as I fear some might want. (If it
is to be removed, it needs to be replaced by another mechanism of
equal or greater power, which no one has so far proposed.)

I am tentatively planning to publish an essay on the TeleRead blog
(and elsewhere) concerning some of the topics I'll raise below.


What Is "Out-Of-Spine" Content?
-------------------------------

In all versions of OEBPS 1.x published to date, content documents
listed in the manifest may be referenced from the Spine, Tours, and
the Guide (and by implication other content documents), and these
content documents need not be in the Spine. Content documents not part
of the Spine are referred to by the PSWG "old-timers" (but not in the
spec) as "out-of-spine" content. For some background, read Section 2.4
of OEBPS 1.2:

http://www.openebook.org/oebps/oebps1.2/download/oeb12-xhtml.htm#sec2.4

Unfortunately, OEBPS is silent regarding how reading systems are to
handle out-of-spine content, but then it is also silent (as far as I
can determine) on whether content documents in the Spine are also to
be rendered when accessible by the user. It is simply assumed
throughout the spec that if the content documents are there, whether
they are in the Spine, or out-of-spine, and accessible to the user
either directly or indirectly via the Spine, Tours and/or Guide
facilities, the reading systems *will* render them on user demand.

For example, if I built an OEBPS reading system, and simply refused to
render all the content documents in the Spine starting with the letter
"a", then from what I gather, the spec allows me to do so. But is that
right? Of course not. There are moral expectations underlying the
entire OEBPS specification which are not explicitly stated since they
are, or should be, patently obvious.

Same for out-of-spine content. If the publisher places it there, and
references it from the Spine as allowed by the spec, then the
publisher has an expectation that all reading systems will render it.
And so long as "out-of-spine" is supported in OEBPS, any reading
system which ignores out-of-spine content, when present in the OEBPS
Publication input into the Reading System, DOES NOT conform to the
OEBPS specification.


Original Intent
---------------

I believe the majority of the original OEBPS authors intended
out-of-spine content to be rendered when referenced from the Spine,
Tours, or Guide -- and to be rendered in innovative ways. Why? The
reason is that, in reality, most publications are non-linear in
content organization, and that the digital publication reading systems
of the future must not be restricted to the physical limitations of
ink-on-paper, but rather should present non-linear content in ways
that best presents the content as it really is. It is important, then,
that OEBPS provides the facilities to represent the non-linearity of
publications, and allow reading systems to likewise innovate for
presenting non-linear publications.

For example, imagine if someone passed a rule saying that the
content of a web "site" must all be placed into a single home page?
Sounds silly, but that's exactly what OEBPS would be if we did not at
least have the out-of-spine feature. And note carefully that a "web
site" *is* a type of digital publication. Do we want the OEBPS of the
future to be throttled so it can't represent the structure of a
typical web site publication, like a snapshot of the Wikipedia? Or how
about hypertext literature?

We must be striving to better represent, digitally, the actual
organization of content, and to provide the means by which reading
systems may innovate to more accurately present such content, with
greater reader comprehension and end-user convenience. I consider the
out-of-spine feature to be the *start* of representing the true
nature of digital publications.

Since it will be brought up whether anyone has used the OEBPS
out-of-spine content, consider Microsoft. Their Reader beautifully
implements OEBPS out-of-spine, and in a way intended by the original
OEBPS authors. In its implementation of OEBPS (Microsoft Reader), an
"out-of-spine" content document is rendered in a pagelet, much like a
"super popup window" -- it's an innovative and powerful feature (and
one which Microsoft curiously never promoted, and I don't even recall
it being mentioned in the several MS Reader manuals that I've
consulted!)

As an ebook publisher in the LIT format, I use the Reader
"out-of-spine"/pagelet feature in all of my OEBPS Publications (which
are then converted to LIT) and have received many positive comments as
to the utility of the pagelet facility enabled by OEBPS out-of-spine
content (I place all notes, auxiliary content, and full-size images in
"out-of-spine".)

As an ebook publisher, I can't imagine NOT having the "out-of-spine"
feature, which is one reason I have not been motivated to publish my
books in the other standard "linear" formats.

And since it will also be brought up whether anyone besides myself is
creating LIT files with pagelets, this is being done not infrequently
according to one fairly major conversion house I spoke with.

The issue we now face is whether we should affirm the "out-of-spine"
feature in "OEBPS-next", or remove it entirely. I see no middle
ground since there should not be any middle ground on something as
critical and important as this.

I don't believe a strong argument can be made to remove it. And I
don't believe that a statement saying "reading systems should support
out-of-spine" (or similar statement) is sufficient to guide reading
system developers, who, if past history is any indication (with
Microsoft being the notable exception), will ignore the "should"
because it is inconvenient for them (I've studied how user agents may
present "out-of-spine" content, and it is NOT a burden on user agent
developers by any stretch of the imagination.)

This is not an issue of inconvenience to reading system developers,
but of what is best for the long-term growth of the digital
publication industry. Remove the out-of-spine feature, and this will
setback the digital publication industry by several years.


What I Propose
--------------

So, here's what I propose that we add to OEBPS-next while keeping
the rest of what we say about the Spine, the Manifest, etc., intact
(focus on the meaning of what is being said below, and not on the
specese which I know Garth can certainly improve!):

"Reading Systems *must* render, upon user demand, a content
document declared in the Manifest when referenced, directly or
indirectly by chained hypertext links, via:

a) Spine,
b) Tours [assuming we continue support for Tours],
c) Guide [assuming we continue support for Guides],
d) Another content document declared in the Manifest and
similarly referenced, and
e) Navigation Set.

The exception is a content document which is not accessible to the
end-user because of rights or network restrictions."

[see postscript at end of this message]

Note the focus on *all* documents in the Manifest, including both
Spine and "out-of-spine". Clearly we should state this general rule,
and it should apply to *all* content documents in the Manifest with no
restrictions of any kind. If a content document is reachable via
hypertext links, directly or indirectly, from the initial entry into
the Spine, then reading systems *must* render it (except when
inaccessible to the end-user as noted.)

The nice thing about this statement is that it allows us to expand
OEBPS support for non-linear content in the future using other
mechanisms, such as the "web paradigm."

So, that is the proposal I am submitting to OEBPS WG. And of course if
I do publish a more general essay on this topic on TeleRead (which is
the most popular ebook blog on the Internet), I will further address
the why's, and the advantages, of "out-of-spine" content to both
publishers and end-users.

Note that the needs or convenience of reading system developers does
not trump what should be the right thing the spec needs to promote,
especially in that implementing "out-of-spine" feature is actually
relatively easy for user agent developers, as my study of this issue
has led me to conclude. (E.g., if Mozilla is used for rendering,
place "out-of-spine" content into a separate browser window with
particular window parameters. I've even thought how one could
implement "out-of-spine" rendering in a limited PDA platform, and it
is doable in a way the reader knows it is "out-of-spine".)


Jon Noring


[p.s. Certainly by the proposed statement a Reading System which
controls the authoring of OEBPS Publications submitted to it can
decide whether or not to support the OEBPS "out-of-spine" feature
since it controls what is input to it. But why would they want to do
this when they can easily support "out-of-spine" and provide a better
reading experience for end-users? It certainly works against the
purpose of "out-of-spine" and the long-term benefit that representing
non-linear publications has for everyone in the digital publication
industry.

And of course what would the Reading System vendor tell publishers who
are building general-purpose OEBPS Publications for Reading Systems
that support "out-of-spine" -- that the publisher "has to linearize"
their OEBPS just for them? As a publisher, I would not like this --
I wonder about *their* competency. And telling publishers they should
never place "out-of-spine" content in the Manifest because [insert a
reason here...] is equally troubling -- I call it a thumbing one's
nose at the spirit and goals of the OEBPS specification which is
striving to bring both conformity and advanced features to the digital
publication universe.

We must include "out-of-spine" in the spec, and do what we can to
encourage publishers to use it, and Reading System developers to
support it. This cannot be accomplished by keeping "out-of-spine"
in the closet as it has been up to now. Giving requirement levels
such as "should" does not meet the muster of the right thing IDPF
should do -- all it does is to continue to confuse the issue for
everyone -- it is effectively the same as removing "out-of-spine"
support entirely.]