Digitale Bücher im Format EPUB 3 selbst erstellen

Alle Bücher sind entweder Träume oder Schwerter. Mit Worten kann man schneiden oder betäuben.
Amy Lowell

Erstellt: 2013-09-04/30 2014-07-09/17 2015-07-01/02 2015-12-10

Autor: Dr. O. Hoffmann (Weitere Projekte des Autors, Kontakt)

Projektmenü; Kurzanleitung EPUB 2; Generator (EPUB 3); Rückmeldung, Diskussion, Hilfe

Inhalt

EPUB gibt es in mehreren Versionen, die sich voneinander unterscheiden. Hauptsächlich ist zwischen den Hauptversionen 2 und 3 zu unterscheiden. Bezogen auf Darstellungsprogramme sind die Unterschiede jedenfalls für einfache Bücher nicht besonders groß. Einfache Bücher lassen sich recht gut mit beiden Versionen erstellen, keine Version bietet da gravierende Vor- oder Nachteile, die sich erst in den Feinheiten zeigen oder wenn ein Autor Inhalte anbieten will, die über die Grundfunktion eines klassischen Buches hinausgehen, etwa Formate, die bei EPUB nicht als Inhaltsformate interpretiert werden müssen, insbesondere auch bei der Verwendung von Audio- und Videodateien.

Von daher gibt es einerseits keinen Grund, warum man einfache Bücher nicht auch in der neuesten Version 3 anbieten kann. Andererseits ist die Einbindung von Inhalten in anderen als den notwendig zu interpretierenden Inhaltsformaten bei beiden Versionen stark verschieden. Version 2 setzt mehr darauf, daß nahezu beliebige Inhalte eingebunden werden können und dann eben mit Alternativen oder mindestens mit vorgegebenen Stilvorlagen auf jeden Fall präsentierbar sind. Version 3 schränkt die Möglichkeiten stärker ein, vereinfacht damit die Verwendung für Autoren einerseits, gibt andererseits aber insbesondere für Audio-Inhalte Formate vor, die mindestens von Darstellungsprogrammen interpretiert werden müssen. Da es sich dabei allerdings nicht um lizenzfreie Formate handelt, ist die Umsetzung dieser Forderung nicht von allen Anbietern von Darstellungsprogrammen wirklich umsetzbar, noch sind die Formate selbst an sich allgemein zugänglich, von daher muß ein Autor auch in Version 3 ähnlich wie in Version 2 zugängliche Alternativen anbieten.

In der praktischen Anwendung ist Version 3 wenigstens für einfache Bücher etwas einfacher zu handhaben. Um die gleiche semantische Qualität der Auszeichnung bei gleichzeitig hoher Zugänglichkeit des Basisinhaltes für beliebige Darstellungsprogramme zu erreichen, eignet sich Version 3 etwas besser als Version 2, die zwar theoretisch in dieser Hinsicht mehr und bessere Möglichkeiten bietet, mit welchen man aber als Autor immer wieder auf Fehler, Mängel und Probleme der Darstellungsprogramme stößt, welche bei Version 3 natürlich nach wie vor vorhanden sind, aber jedenfalls dem durchschnittlichen Leser nicht so offensichtlich offenbart werden wie bei semantisch gleichwertig ausgezeichnetem Inhalt der Version 2.

Obwohl eine kleine (ganz gut funktionierende) Teilmenge der Version 2 immer noch reichlich genutzt wird, kann es sich also sicherlich lohnen, statt dieser kleinen Teilmenge gleich Version 3 zu verwenden, welche etwas einfach zu handhaben ist, gleichzeitig aber ohne die Nachteile der Version 2 im ähnlichen Umfange Möglichkeiten bietet, semantisch gut ausgezeichnete Bücher zu erstellen.

Bei EPUB 3 ergeben sich also einige technische Änderungen gegenüber EPUB 2. Primär wendet sich diese Version ab vom Format DAISY beziehungsweise DTB. Als Inhaltsdokumente gelten hier Dokumente im Format XHTML und SVG [SVG], wobei jeweils nur spezielle Untermengen dieser Formate zu verwenden sind.

Besonders kritisch zu sehen ist, daß sich EPUB 3 bereits auf die XML-Variante von HTML5 [HTML5] bezieht - wobei EPUB 3 eine Empfehlung von 2011 ist. Version 3.0.1 ist 2014-06 herausgekommen. Auch zu diesem Zeitpunkt war HTML5 allerdings noch nicht das Stadium einer Spezifikation oder Empfehlung erreicht und der Inhalt konnte sich also jederzeit ändern - und zwischen 2011 und 2014 hat es bereits gravierende Änderungen gegeben, zudem stehen einige Elemente und Attribute auf der Abschußliste, die es dann auch nicht in die Empfehlung vom 2014-10-28 geschafft haben. Darüber hinaus war bereits lange vor dem Erreichen des Status einer Empfehlung eine Überarbeitung HTML5.1 in Arbeit, was auch so interpretiert werden kann, daß HTML5 ähnlich wie HTML3.x nicht als wirklich brauchbar angesehen wird, also eher ein Fehlgriff ist.

EPUB 3 legt nun nicht fest, auf welchen Arbeitsentwurf es sich bezieht, das genaue Vokabularium ist von daher schon nicht genau definiert. Die Empfehlung zu HTML5 enthält tendenziell eher ein kleineres, zuverlässigeres Vokabularium als frühere Arbeitsentwürfe, man sollte sich also darauf beschränken und sich primär auf das konzentrieren, was entweder bereits in XHTML im Umfang der Versionen 1.1 vorhanden war, zusätzlich kommen dann noch die wenigen neuen Elemente hinzu, welche eine semantische Bedeutung haben und für Bücher besonders relevant sind, wobei diese Kollektion deutlich kleiner ist als jene vom DTB, welches aber mit Version 3 als Inhaltsformat verworfen wurde.

Problematisch ist bei Dokumenten gemäß HTML5, daß diese Formatversion es nicht ermöglicht, mit dem Format selbst anzugeben, welche Version verwendet wird. Dies wird nur bei Dokumenten innerhalb des EPUB-Archivs impliziert. Sonst müssen Autoren praktisch auf Metainformationen ausweichen, um zuverlässige Versionsangaben zu machen, die den unsinnigen Einschränkungen von HTML5 nicht widersprechen.

Erfreulich ist hingegen, daß endlich SVG als Format für eigenständige Inhaltsdokumente eingeordnet wurde, während in EPUB 2 die Interpretation zwar erforderlich ist, aber nicht notwendig als eigenständiges Inhaltsdokument, sondern nur in andere Dokumente eingebettet. Der Umfang von SVG ist allerdings ähnlich eingeschränkt wie bei EPUB 2. Insbesondere ist leider immer noch die deklarative Animation ausgeschlossen, obgleich es dafür in SVG gut ausgearbeitete Möglichkeiten hinsichtlich einer zugänglichen Gestaltung des Dokumentes gibt, auch wenn Animation nicht darstellbar sein sollte. Dieser Mangel führt dann also wie gehabt dazu, daß zahlreiche Inhalte auch mit EPUB 3 noch nicht realisierbar sind, die für das Publikum hätten lohnenswert sein können.

Weitere Änderungen betreffen mehr Details, die im Folgenden ebenfalls erläutert werden, mit Schwerpunkt allerdings mehr darauf, ein korrektes Buch im Format EPUB 3 zu erstellen, als die Unterschiede im Einzelnen herauszuarbeiten. Die Details führen in weiten Bereichen dazu, daß von Autoren seltener verwendete oder auch oft falsch oder gar nicht implementierte Möglichkeiten, die es in Version 2 noch gegeben hat, in Version 3 ausgeschlossen werden. Im Schnitt ergibt sich so in Version 3 eine deutliche Verarmung der Möglichkeiten, wohingegen die Version oft werbewirksam als mit mehr Möglichkeiten ausgestattet gelobt wird. Einige Dinge, die auch in Version 2 bereits möglich waren, sind in Version 3 meist lediglich besser durchdacht, für Autoren dadurch aber nicht notwendig einfacher umzusetzen. Einige Dinge sind in Version 3 aber auch wirklich etwas vereinfacht. Nimmt man allerdings die vielfach genannte Möglichkeit der Interaktivität, die es in Version 3 angeblich geben soll, so ist anzumerken, daß gerade im Format SVG wie gehabt, interaktive und deklarative Animation ausgeschlossen ist - das Gerücht ist also unzutreffend und bezieht sich vermutlich hauptsächlich darauf, daß Multimedia-Dateien interaktiv und deklarativ angesteuert werden können. Ansonsten ist es in Version 3 nunmehr lediglich erlaubt, die Inhalte mit java-script zu dekorieren, allerdings wie gehabt in einer zugänglichen Form, also daß alle Inhalte auch verfügbar sind, wenn solche Skripte nicht ausgeführt werden. Diese Forderung unterbindet formal, daß unzugängliche Inhalte erstellt werden. Weil die Forderung aber ohnehin schlecht automatisch zu prüfen ist, stellt dies tatsächlich eine systematische Verschlechterung der Zugänglichkeit des Formates dar. Nutzer solcher Bücher tragen mehr als zuvor das Risiko, daß Inhalte von Büchern unzugänglich sind. Je nach Gestaltung kann es sogar sein, daß diese Mängel nicht unmittelbar auffallen, was es den Nutzern dann auch erschwert, etwa gekaufte mangelhafte Bücher zurückzugeben, weil ihnen der Mangel nicht unmittelbar auffällt.

Autoren können solche Mängel natürlich leicht vermeiden, indem sie einfach gar keine Skripte in einem Buch verwenden. Die Verantwortung dafür liegt aber nun eindeutig bei diesen, während in Version 2 eine entsprechende Prüfung auf solche Mängel noch recht einfach automatisch durchgeführt werden konnte, um den Mangel schon vor einer Veröffentlichung zu offenbare.

Archiv-Dateien

Die Struktur der formalen Archivdateien bleibt weitgehend unverändert, also ist wie gehabt die Datei 'mimetype' mit dem Inhalt "application/epub+zip" die erste Datei im Archiv und wird nicht komprimiert. Auch die möglichen Dateien im Verzeichnis 'META-INF' bleiben die gleichen. Auch der Inhalt der Datei 'container.xml' kann unverändert bleiben:

<?xml version="1.0"?>
<container version="1.0"
  xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
   <rootfiles>
      <rootfile
        full-path="Inhalt/index.opf"
        media-type="application/oebps-package+xml"/>
   </rootfiles>
</container>

OPF-Dokument

Beim OPF-Dokument ergeben sich einige kleinere Unterschiede für EPUB 3 gegenüber EPUB 2. Zunächst ändert sich natürlich die Versionsangabe des Formates selbst von 2 auf 3. Die gilt dann auch für Version 3.0.1, was wiederum bei älteren Programmen und Validatoren für Verwirrung sorgen kann, weil diese dann unvermittelt auf neue Strukturen treffen können, die für sie nicht interpretierbar sind. Mit einer abweichenden Versionsangabe könnten sie immerhin eine Warnung an die Leser ausgeben, daß die im Buch verwendete Version nicht bekannt ist, es also zu Interpretationsproblemen kommen kann. Die Verwirrung ist eigentlich unnötig und deutet an, daß die Aktualisierung zu Version 3.0.1 nicht besonders gut durchdacht ist.

Anders als in der Version 2 kann man in der Version 3 endlich für das gesamte Dokument die Sprache angeben, dazu dient wie üblich das Attribut xml:lang beim Wurzelelement package.

Ebenfalls beim Wurzelelement kann mittels des Attributes dir die normale Leserichtung angegeben werden, also entweder 'ltr' für von links nach rechts, oder 'rtl' für von rechts nach links. Von oben nach unten etwa oder umgedreht ist nicht vorgesehen.

Mit dem Attribut prefix des Wurzelelementes können im Bedarfsfalle Präfixe definiert werden. Der Wert ist eine mit Leerzeichen separierte Liste von Präfixdefinitionen. Diese Präfixe dienen nicht der Angabe von Namensräumen, sondern die hier definierten Präfixe dienen lediglich als Abkürzungen bei der Verwendung von CURIEs.

Die Version 3 hat auch einige vordefinierte Präfixe:

'dcterms'
'http://purl.org/dc/terms/' (die Terme von Dublin Core [DCT])
'marc'
'http://id.loc.gov/vocabulary/' (nähere Angaben zu Autoren und Mitarbeitern)
'media'
'http://www.idpf.org/epub/vocab/overlays/#' (für Medienüberlagerungsdateien)
'onix'
'http://www.editeur.org/ONIX/book/codelists/current.html#' (Eigenschaften von Büchern)
'xsd'
'http://www.w3.org/2001/XMLSchema#' (Typen von Werten)
'schema'
'http://schema.org/' (Nur in Version 3.0.1)
'rendition'
'http://www.idpf.org/vocab/rendition/#' (Nur in Version 3.0.1)

Diese dürfen nicht mit dem Attribut prefix überschrieben werden, noch sind für die Lokalisierungen andere Präfixe zu notieren.

Eine korrekte Angabe zu prefix sieht zum Beispiel wie folgt aus:

prefix="
  cc: http://creativecommons.org/ns#
  foaf: http://xmlns.com/foaf/spec/
  dbp: http://dbpedia.org/ontology/
  "

Hinter dem Präfix-Doppelpunkt soll dabei jeweils mindestens ein einfaches Leerzeichen stehen, aber kein Zeilenumbruch.

Gemäß Inhaltsmodell des Wurzelementes package ist das erste Kindelement wie gehabt metadata, gefolgt von manifest, gefolgt von spine. Abweichend von Version 2 ist in Version 3 das dann optional folgende Element guide als veraltet gekennzeichnet, sollte also nicht mehr verwendet werden. Darauf kann optional das neue Element bindings folgen.

In Version 3.0.1 kann darauf optional das neue Element collection folgen, eine Möglichkeit, darauf hinzuweisen, daß bestimmte Inhalte einen eng miteinander verknüpften Inhalt haben, der zusammengehört, etwa bei Konversionen oder im Druck als zusammengehöriger Inhalt angesehen werden soll.

Die Inhalte der bereits von Version 2 bekannten Elemente sind natürlich in Version 3 ähnlich. Anders als in Version 2 kann in Version 3 das Element metadata keine spezifischen Attribute haben. Neben den bereits in Version 2 erlaubten Kindelementen können auch Elemente link notiert werden. Das Element meta hat zudem seine Bedeutung geändert.

Die Grundstruktur der Datei sieht also wie folgt aus:

<?xml version="1.0" encoding="UTF-8" ?>
<package version="3.0" 
    unique-identifier="id"
    xmlns="http://www.idpf.org/2007/opf">
  <metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    <!-- ... Metainformationen -->
  </metadata>
  <manifest>
    <!-- ... Verzeichnis der Inhalte -->
    <item id="bsp.svg" href="bsp.svg" media-type="image/svg+xml"/>
  </manifest>
  <spine>
    <!-- ... Reihenfolge der Inhaltsdateien-->
     <itemref idref="bsp.svg"/>
  </spine>
  <bindings>
    <!-- Optional: Skript-Verhalten bei nicht interpretierten Formaten -->
    <mediaType media-type="application/x-x" handler="..." />
  </bindings>
</package>

Metainformationen

Die Metainformation werden wie gehabt im Element metadata jeweils mit Elementen von Dublin Core angegeben [DC]. Anders als bei Version 2 ist dabei der Elementsatz wirklich auf die 15 Basiselemente von Dublin Core eingeschränkt.

Jedes dieser Elemente kann ein Attribut id mit einem Fragmentidentifizierer haben. Dieses Attribut ist in EPUB 2 und 3 definiert, nicht von Dublin Core. Formal notwendig wäre also eigentlich, wie bereits für Version 2 diskutiert, ein passendes Präfix, welches in den Spezifikationen aber nicht angegeben ist. Es ist also der Namensraum von OPF anzunehmen, also 'http://www.idpf.org/2007/opf'.
Ohne passendes Präfix für das Attribut würde dieses so interpretiert werden, wie es für das Element festgelegt ist, was aber von Dublin Core zu definieren wäre, nicht von EPUB 3 - ähnliches gilt auch für andere Attribute ohne Präfix. Elemente von Dublin Core haben allerdings in ihrem Namensraum keine definierten Attribute. Daher ist ein Präfix notwendig. Leider ist dies in der Spezifikation von EPUB 3 nicht angegeben, die Beispiele ohne das Präfix in der Spezifikation sind durchgehend fehlerhaft (was allerdings vermutlich von den zuständigen Autoren der Spezifikation bestritten werden wird, die das alles nicht so eng sehen werden). Während ich bei der Anleitung zu Version 2 noch kein Präfix bei den Beispielen notiert habe, verwende ich für die Beispiele für Version 3 nun durchgehend ein Präfix für solche Attribute, ohne Korrekturen in den Empfehlungen für EPUB ist jedenfalls beides keine befriedigende Lösung für den Mangel in den Empfehlungen.

Statt wie in Version 2 Verfeinerungen der Elementbedeutungen mit Attributen aus einem OPF-Namensraum vorzunehmen, wird in Version 3 ein komplett anderes Konzept verfolgt. Ein Element meta dient im Bedarfsfalle dazu, diese Verfeinerung vorzunehmen. Dabei ist für Autoren zu bedenken, daß dieses neue Konzept komplett rückwärtsinkompatibel zu alten Darstellungsprogrammen ist, diese Verfeinerungen sind also für alte Programme nicht zugänglich. Eine rückwärtskompatible Schreibweise ist in Version 3 nicht vorgesehen. Daher ist zum empfehlen, sämtliche Metainformationen in einem eigenen Inhaltsdokument zu wiederholen.

Wie gehabt kann bei den Elementen title, contributor, coverage, creator, description, publisher, relation, rights und subject das Attribut xml:lang verwendet werden. Neu ist die Möglichkeit, wie für das Wurzelelement die Schreibrichtung festzulegen. Wie dort ist dafür das Attribut dir vorgesehen, also entweder der Wert 'ltr' für von links nach rechts, oder 'rtl' für von rechts nach links. Von oben nach unten etwa oder umgedreht ist nicht vorgesehen. Ähnlich wie bei id ist für dies Attribut ein Präfix notwendig, der das Attribut dem Namensraum 'http://www.idpf.org/2007/opf' zuordnet, wie bereits für den Fragmentidentifizierer erläutert. Da die Kodierung mittels UTF-8 allerdings bereits die Schreibrichtung automatisch festlegt, ist eine Angabe nur für solche Zeichenkombinationen sinnvoll, wenn für diese keine normal und automatisch festgelegten Schreibrichtung festgelegt ist. Interessanter Weise steht in der Spezifikation von EPUB 3 sogar, daß die automatischen Angaben gemäß UTF-8 Vorrang haben, was dann das Attribut in der Praxis auch gleich wieder überflüssig macht - auch hier erweist sich EPUB 3 einmal mehr als reichlich unausgegoren.

Die Angabe der Dublin-Core-Elemente identifier, title und language ist wie gehabt erforderlich. Hinzu kommt als erforderlich noch ein spezielles Element meta mit einer Angabe zur letzten Änderung des Dokumentes. Ein minimales Beispiel sieht etwa so aus:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
     xmlns:opf="http://www.idpf.org/2007/opf">
<!-- Eindeutige Buchidentifikation, hier mit einer UUID -->
    <dc:identifier opf:id="id">eb3035a7-d3ff-476f-8fb5-da335893873b</dc:identifier>
<!-- Der Buchtitel -->
    <dc:title xml:lang="de">Auf dem Strich und an der Leine</dc:title>
<!-- Angabe zur hauptsächlich verwendeten Sprache -->
    <dc:language>de</dc:language>
<!-- Angabe zur letzten Änderung -->
    <meta property="dcterms:modified">2013-05-28T17:07:34Z</meta>
</metadata>

Es darf exakt ein Element meta geben, welches eine solche Angabe zur letzten Änderung hat. Der Elementinhalt muß folgender Form folgen: jjjj-mm-ttThh:mm:ssZ.
Also der Inhalt beginnt mit vier Ziffern für die Jahreszahl, gefolgt von einem Minuszeichen '-', zwei Ziffern für einen Monat, ein weiteres Minuszeichen, zwei Ziffern für einen Tag, ein 'T', gefolgt von zwei Ziffern für Stunden, ein ':', dann zwei Ziffern für Minuten, ein ':', zwei Ziffern für Sekunden und ein Z. Die Notation ähnelt dem internationalen Datumsformat, schränkt dies aber weiter ein, etwa können keine Bruchteile von Sekunden notiert werden oder auch keine Zeitzonen. Dies ist auch eine wesentliche Einschränkung gegenüber dem, was Dublin Core eigentlich für diesen Term vorsieht.

Weitere Elemente meta mit anderen Angaben sind natürlich erlaubt.
Eine Schema-Angabe beim Identifizierer mittels opf:scheme ist in Version 3 nicht mehr vorgesehen, stattdessen gibt es ein allgemeineres Verfahren mit dem Element meta.

Element meta

Das Element meta kann allgemein verwendet werden, um Metainformationen anzugeben oder aber auch, um Metainformationen anderer Elemente oder deren Bedeutung zu verfeinern. Der Elementinhalt ist einfacher Text. Der Prosatext von EPUB 3 sieht allerdings nicht vor, daß xml:lang verwendet werden kann, um festzulegen, in welcher Sprache der Inhalt verfaßt ist. Auf Nachfrage hin hat sich allerdings herausgestellt, daß das Attribut gemäß maschinenlesbarem Schema auch bei meta verwendet werden kann. Die fehlende Erwähnung dieses Umstandes ist ein weiteres Indiz dafür, daß EPUB 3 nicht besonders gut durchdacht ist. Allerdings kann man ja nun beim Wurzelelement package die Sprache angeben, was man dann auch wohl besser tut. Das reicht dann immerhin, wenn alle Nachfahren, bei denen kein abweichendes xml:lang notiert ist, in der für das Wurzelelemnt angegebenen Sprache verfaßt sind.

Erforderlich ist die Angabe des Attributes property. Es gibt die Eigenschaft einer Metainformation an. Angelehnt an RDFa [RDFa] wird eine CURIE verwendet. Dabei wird eine URI in zwei Bestandteile aufgeteilt. Der erste Teil wird per Präfix definiert und umfaßt einen Teil der URI, welcher oft wiederverwendet wird. In der CURIE wird dieser Teil durch den Präfix mit folgendem Doppelpunkt repräsentiert. Der Teil hinter dem Doppelpunkt besteht aus dem Teil der URI, welcher sich nicht oft wiederholt und somit nicht bereits durch das Präfix festgelegt ist.
Wenn man mag, kann man so also insbesondere die alten Verfeinerungen von Version 2 verwenden. Ist etwa das Präfix xmlns:opf="http://www.idpf.org/2007/opf" bereits definiert, so kann man etwa für die Verfeinerung des Buchidentifizierers property="opf:scheme" verwenden.

Wird kein Präfix angegeben, wird folgende Adresse für das Vokabular angenommen: http://idpf.org/epub/vocab/package/#

Zur Verfeinerung der Bedeutung eines anderen Elementes kann das Attribut refines verwendet werden. Der Wert ist dann ein Fragmentidentifizierer eines anderen Elementes mit Metainformationen oder eines, für welches Metainformationen angegeben werden sollen. Für obiges Beispiel kann man so formulieren:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
<!-- Eindeutige Buchidentifikation, hier mit einer UUID -->
    <dc:identifier opf:id="id">eb3035a7-d3ff-476f-8fb5-da335893873b</dc:identifier>
    <meta property="identifier-type" refines="#id">UUID</meta>
<!-- Der Buchtitel -->
    <dc:title xml:lang="de">Auf dem Strich und an der Leine</dc:title>
<!-- Angabe zur hauptsächlich verwendeten Sprache -->
    <dc:language>de</dc:language>
<!-- Angabe zur letzten Änderung -->
    <meta property="dcterms:modified">2013-05-28T17:07:34Z</meta>
</metadata>

meta kann ebenfalls ein Attribut id mit einem Fragmentidentifizierer haben und ein Attribut scheme mit einer Angabe, welchem Schema der Inhalt des Elementes folgt. Der Wert von scheme ist wieder eine CURIE.

Vordefinierte Werte für property sind:

'alternate-script'
Alternativer Wert in einer anderen Sprache, die per xml:lang anzugeben ist.
'display-seq'
Angabe zur Einordnung in einer Sequenzreihenfolge, etwa bei mehreren Titel kann man so angeben, in welcher Reihenfolge die Titel anzugeben sind, indem jedem Titel eine solche Zahl zugewiesen wird. Der Elementinhalt ist dann entsprechend eine ganze Zahl ohne Vorzeichen.
'file-as'
Eine normalisierte Form der Angabe, statt einen Autor etwa einfach als 'Dr. Olaf Hoffmann' anzugeben, kann man dies damit verfeinern, indem man etwa schreibt 'Dr. Hoffmann, Olaf'.
'group-position'
Gehört das Werk zu einer Gruppe von Veröffentlichungen, kann damit eingeordnet werden, an welcher Stelle einer Reihenfolge es in der Gruppe gehört. Der Wert ist eine ganze Zahl ohne Vorzeichen oder derartige Zahlen mit Punkten separiert, also etwa '7' oder aber auch '7.4.3.8'.
'identifier-type'
Der Typ des Identifizierers, also etwa 'UUID', 'DOI', 'URN', 'IRI', 'PURL' etc; sofern man ein Schema angibt, kann das natürlich auch noch weiter konkretisiert werden:
<meta refines="#id" property="identifier-type" scheme="onix:codelist5">15</meta>
'meta-auth'
Angabe einer Autorität für die Angabe von Metainformationen. Der Wert ist dann einfacher Text.
'role'
Die Rolle von Autoren oder Mitarbeitern. Analog zu Version 2 ist hier also aus einer entsprechenden Liste zu wählen, etwa:
<meta refines="#creator" property="role" scheme="marc:relators">aut</meta>
'title-type'
Art des Titels. Der Wert ist eine Zeichenkette. Folgende Zeichenketten sind reserviert/vordefiniert:
'main'
Haupttitel
'subtitle'
Untertitel
'short'
Kurztitel
'collection'
Sammlungstitel
'edition'
Titel der Ausgabe
'expanded'
Erweiterter Titel

In Version 3.0.1 kommen ferner hinzu:

'belongs-to-collection'
Gibt an, zu welcher Sammlung der Eintrag gehört.
'collection-type'
Typ der Sammlung, mit dem Attribut scheme sollte dann ein Schema angegeben sein, sofern nicht einer der beiden folgenden Werte als Elementinhalt von meta notiert ist: 'series' für eine nicht abgeschlossene Serie von Werken, wo es also von Zeit zu Zeit neue Werke gibt oder 'set' für eine abgeschlossene Sammlung von Werken, die zusammen eine Einheit bildet.
'rendition:flow'
Als Werte gibt es 'paginated' für automatische Seiteneinteilung, 'scrolled-continuous' für eine rollbare Darstellung statt einer Seiteneinteilung für das gesamte Buch, 'scrolled-doc' für eine Seiteneinteilung je Einzeldokument, welches wiederum rollbar darstellbar ist, 'auto' überläßt dem Darstellungsprogramm die Art der Darstellung, dies ist die Voreinstellung.

Wenn man seine Inhalte gut strukturiert hat, wird man typisch 'scrolled-doc' als bevorzugte, sinnvolle Präsentation des Inhaltes vorschlagen wollen, somit notiert man:

<meta property="rendition:flow">scrolled-doc</meta>

Das ist natürlich immer nur als Vorschlag zu verstehen, das Publikum kann im Darstellungsprogramm auch Möglichkeiten haben, die Präsentation auf etwas anderes umzustellen. Einige Programme oder Programmerweiterung scheinen sich auch stark darauf versteift zu haben, das Verhalten von gedruckten Büchern auf digitale zu übertragen, diese könnten es dann schlicht auch bevorzugen, solche Vorschläge von Autoren zu ignorieren. Diese werden dann weiterhin versuchen, eine inhaltliche sinnlose Seiteneinteilung vorzunehmen, statt eine für den Inhalt angemessene strukturierte Darstellung zu erwägen, wie vom Autor vorgeschlagen. Der Hang am Seitenkonzept von gedruckten Büchern bleibt hier rätselhaft, weil diese ja historisch im Grunde auch nur eine Notlösung war, Inhalt auf bequem verfügbares und transportierbares Papier zu arrangieren - bei digitalen Büchern ohne Papier also eher ein Kuriosum, sich ausgerechnet darauf zu beziehen. Der Versuch, mit relativ simplen Programmen inhaltlich strukturierte Dokumente automatisch auf solchen Pseudoseiten zu arrangieren, sorgt natürlich auch für reichlich zusätzliche Probleme. Bei gedruckten Büchern gibt es schließlich nicht nur zum Spaß eine ganze Berufsgruppe, welche sich damit beschäftigt, Inhalte von Büchern auf einzelne Papierseiten ansprechend anzuordnen.

Ein weiterer neuer Wert, der in Version 3.0.1 eingeführt wurde, beschäftigt sich mit dem Layout. Dabei geht es dann nicht nur um die Einteilung entweder auf Seiten oder um eine rollbare Präsentation, sondern es geht um das prinzipielle Darstellungskonzept. Auf der einen Seite steht das von XHTML, wo sich die Präsentation des Inhaltes an den verfügbaren Platz anpaßt, indem Text oder Inhalt automatisch umgebrochen wird und die Schriftgröße fest bleibt, bevorzugt, wie vom Nutzer optimal eingestellt. Dann gibt es ein Konzept, welches mit dem Verhalten vergleichbar ist, welches man bei einem SVG-Dokument bekommt, wenn die viewBox festgelegt ist und ein festes Aspektverhältnis verwendet wird und width und height nicht angegeben sind oder auf Prozentwerte festgelegt sind. Hier paßt sich der Inhaltsbereich durch Skalierung an den verfügbaren Platz an.

Bei EPUB 3.0.1 kann nun also auch das SVG-Verhalten auf XHTML angewendet werden. Dazu muß im Wesentlichen ein Äquivalent zu viewBox angegeben werden. Problematisch ist dabei bei vorhandenem Textinhalt, daß das Publikum die Schriftgröße immer nach eigenen Gesichtspunkten einstellen kann, zudem der Platzbedarf für generischen Schriftfamilien vom Autor gar nicht präzise bestimmbar ist, von daher kann der Autor gar nicht wissen, wieviel Platz für den Textinhalt benötigt wird.

Dabei ist ferner zu beachten, daß insbesondere Verkleinerungen des Inhaltes die Lesbarkeit für den Nutzer verschlechtern kann. Der Inhalt kann dabei auch komplett unlesbar werden.

Genau genommen gibt es auch noch ein anderes Präsentationskonzept, statt den Inhalt im Bedarfsfalle zu rollen, kann der Inhalt auch relativ zum Darstellungsbereich verschoben werden, horizontal und vertikal. Dies ist von einigen Programmen für Mobiltelephone bekannt, wo man mit den Fingern auf dem Bildschirm herumgrabbelt, um sich so verborgene Inhalte zugänglich zu machen. EPUB 3.0.1 selbst legt nicht fest, in welcher Weise der Inhalt zugänglich gemacht wird, der nicht in den Darstellungsbereich des Anzeigegerätes paßt, wenn ein sogenanntes fixiertes Layout vom Autor favorisiert wird. Prinzipiell kann ein Darstellungsbereich überstehenden Inhalt auch einfach gar nicht anzeigen. Auch hier zeigt sich einmal mehr, daß diese neue Möglichkeit von EPUB 3.0.1 reichlich unausgegoren daherkommt, zwar kann ein Autor nun explizit vorgeben, wie groß sein jeweiliges Dokument (aber nur in Pixeln!) sein soll, es bleibt aber unklar, was passiert, wenn der Darstellungsbereich des Anzeigegerätes kleiner ist als die vom Autor gewünschte Größe.

property mit dem Wert 'rendition:layout' kann notiert werden, um das Layout für das gesamte Buch festzulegen. 'reflowable' ist das normale Verhalten und wird auch verwendet, wenn 'rendition:layout' nicht angegeben ist. 'pre-paginated' schaltet in den Modus für eine fixierte Seitengröße, also zur Skalierung oder Verschiebung überstehender Inhalte - oder was auch immer das Programm mit überstehendem Inhalt anzustellen gewillt ist.

property mit dem Wert 'rendition:viewport' ist im Falle von 'pre-paginated' zu verwenden, um den Anzeigebereich festzulegen. Der Wert ist dann sinngemäß 'width=x, height=y' oder 'height=y, width=x'. Dabei sind 'x' und 'y' Zahlen, die CSS-Pixel repräsentieren. 'x' steht für die Breite, 'y' für die Höhe. Dabei zu bedenken ist, daß solch ein Pixel auf 1/96 inch festgelegt ist, also 2.54cm/96. CSS 2.1 stellt den Darstellungsprogrammen allerdings frei, wie ein inch oder cm präsentiert wird.
In der Praxis gibt es also keinen Bezug zu einer absoluten Größe. Rätselhaft bleibt hier auch, warum man keine sinnvollen Einheiten von CSS verwenden darf wie etwa em oder ex, wobei auch das nur begrenzt nützlich ist, weil man damit ja auch nur festlegen kann, ungefähr wie viele Zeichen in einer Zeile dargestellt werden sollen.
Im Wesentlichen wird mit der property also das Aspektverhältnis festgelegt. Offenbar werden dann in Zweifelsfalle einfach nicht alle Bereiche des Darstellungsbereiches verwendet, um Inhalt darzustellen. Bei jedem XHTML-Dokument ist dann anzugeben, welche Breite und Höhe es hat, überstehender Inhalt wird dann abgeschnitten. Dies passiert auf inhaltlicher Ebene, also nicht für jede gegebenenfalls vorhandene Stilvorlage einzeln - was bereits zeigt, wie unausgegoren und unsinnig das ganze Konzept ist.
Ohne vom Autor festlegbare Schriftgröße (kann ja vom Nutzer überschrieben werden) ergibt sich damit aber auch keine nähere Kontrolle, was wie im so festgelegten Darstellungsbereich angezeigt wird.
Sinnvoll kann das Vorgehen allenfalls sein, wenn ein Dokument nur eine dekorative Pixelgraphik einbindet, also Strukturen, die irgendwie nur auf Pixeln basieren, also kein Text und keine frei skalierbaren Graphiken.

Zu beachten ist, daß entsprechende Angaben bei jedem von 'pre-paginated' betroffenen Inhaltsdokument abermals mit eigener Syntax anzugeben sind, siehe dazu den entsprechenden Abschnitt zu Erweiterungen von XHTML.
Ingesamt, mit ungeeigneten Pixeleinheiten und nicht definiertem Verhalten der Darstellungsprogramme hinsichtlich vom Nutzer eingestellter Schriftgröße zusammen mit der möglichen Skalierung aufgrund der Angaben des Autors und der vom Darstellungsprogramm abhängigen Interpretation der Größe eines Pixels gemäß CSS 2.1 ergibt sich hier ein Minenfeld für Autoren und Leser, welches primär Autoren von vorne herein vermeiden können, indem sie auf solche Angaben komplett verzichten.
Problematisch ist das Merkmal natürlich auch im Zusammenhang mit Dokumenten, die nicht zu den Inhaltsformaten gehören, also Dokumente in Inhaltsformaten als Alternativen haben. Die Alternativen können natürlich andere Größen haben oder die Größe könnte für eine Alternative sinnvoll wieder nicht festgelegt werden.

Wird zusätzlich mit refines auf ein spezifisches Inhaltsdokument (das itemref) verwiesen, so gilt die Angabe nur für dieses Dokument, sonst für alle.

Als Beispiel die entsprechenden Metainformationen, die in metadata anzugeben sind, um ein festes Aspektverhältnis zu erreichen:

<meta property="rendition:layout">pre-paginated</meta>
<meta property="rendition:viewport">width=600, height=800</meta>
<meta property="rendition:viewport" refines="#ir_umschlag">width=600, height=900</meta>

Und dann im spine (siehe unten) etwa:

<itemref id="ir_umschlag" idref="umschlag"/>
<itemref idref="k1"/>
<itemref idref="k2"/>

Elemente nach Dublin Core

Der sonstige Inhalt von metadata besteht also aus dem Basissatz der 15 Elemente von Dublin Core. Verfeinerungen sind in Version 3 mit den Elementen meta oder link anzugeben, nicht wie in Version 2 mit Attributen aus dem Namensraum von OPF. Ansonsten ist die Bedeutung und Verwendung der Elemente die gleiche wie für Version 2.

Bei der Buchidentifikation muß man sich also für die Angabe des Schemas etwas Neues einfallen lassen. Um das alte Verfahren anzuwenden, kann obiges Beispiel verwendet werden. Es geht allerdings noch eleganter, weil man nun direkt die Spezifikation der jeweiligen Buchidentifikation referenzieren kann.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
     xmlns:olaf="http://hoffmann.bplaced.net/epub/meta.php"
     xmlns:opf="http://www.idpf.org/2007/opf">
<!-- Eindeutige Buchidentifikation, hier mit einer EBI -->
    <dc:identifier opf:id="id">
      [Dr. Olaf Hoffmann|Digitale Bücher im Format EPUB selbst erstellen|1] 
      [2013-05-18T21:12:37.003Z] 
      [20|Ij8-q61-3PO-mio-8714]
    </dc:identifier>
    <meta property="identifier-type" scheme="olaf:#ebi" refines="#id">EBI</meta>
<!-- Eindeutige Buchidentifikation, hier mit einer UUID -->    
    <dc:identifier  opf:id="id2">eb3035a7-d3ff-476f-8fb5-da335893873b</dc:identifier>
    <meta property="identifier-type" refines="#id2">UUID</meta>    
<!-- ... -->
</metadata>

Für das Element title ein Beispiel einer Verfeinerung, hier ein Titel und ein Untertitel mit Angabe der gewünschten Reihenfolge:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
     xmlns:opf="http://www.idpf.org/2007/opf">
<!-- Eindeutige Buchidentifikation, hier mit einer UUID -->
    <dc:identifier opf:id="id">eb3035a7-d3ff-476f-8fb5-da335893873b</dc:identifier>
    <meta property="identifier-type" refines="#id">UUID</meta> 
<!-- Der Buchtitel -->
    <dc:title  opf:id="id_title" xml:lang="de">Auf dem Strich und an der Leine</dc:title>
    <meta refines="#id_title" property="title-type">main</meta>
    <meta refines="#id_title" property="display-seq">1</meta>
<!-- Der Untertitel -->
    <dc:title  opf:id="id_sub" xml:lang="de">Öffentliche Kunst in Hannover</dc:title>
    <meta refines="#id_sub" property="title-type">subtitle</meta>
    <meta refines="#id_title" property="display-seq">2</meta>
<!-- Angabe zur hauptsächlich verwendeten Sprache -->
    <dc:language>de</dc:language>
<!-- Angabe zur letzten Änderung -->
    <meta property="dcterms:modified">2013-05-28T17:07:34Z</meta>
</metadata>

Neu in Version 3 ist auch die Einschränkung. daß jeweils nur maximal ein Element date, source, type verwendet werden darf. Diese Einschränkung wird für source und type in Version 3.0.1 zurückgenommen.

source wird in Version 3 eingeschränkt auf Angaben zu gedruckten Quellen, in 3.0.1 wird diese Einschränkung wieder aufgehoben.
Warum man in Version 3 nicht mehrere Quellen für ein Werk angeben darf, bleibt komplett unklar. Warum diese klassisch gedruckt sein müssen, bleibt ebenfalls ein Geheimnis der Autoren dieser Empfehlung. Offenbar ist es einfach, diese unsinnige Einschränkung zu umgehen, indem man die Quellenangaben komplett mit Termen von Dublin Core vornimmt, die per Element meta notiert werden können.
Vermutlich wurden daher diese unsinnigen Einschränkungen in Version 3.0.1 wieder aufgehoben.

Da ein Buch auch aus unterschiedlichen Bestandteilen zusammengesetzt sein kann, bleibt auch unklar, warum man nur einen Typ angeben darf, denn oft passen mehrere Typen zu einem Buch. Daher wurde dann wohl auch dies wieder in Version 3.0.1 aufgehoben.

In Version 3 wird das Element date eingeschränkt auf die Bedeutung eines Veröffentlichungsdatums. Da allerdings date im Namensraum von Dublin Core definiert ist und diese Einschränkung oder Verfeinerung nicht durch ein Attribut im eigenen Namensraum von OPF vorgenommen wird, ist sie wohl als unwirksam oder unsinnig anzusehen. Autoren verwenden stattdessen für den Zweck besser den Term issued von Dublin Core, um ein Veröffentlichungsdatum eindeutig definiert anzugeben. Dies wird dann samt Präfix beim Element meta als Wert von property notiert, der Inhalt des Elementes ist dann das Veröffentlichungsdatum.

Hinsichtlich des Datums ist zudem angegeben, das man Terme von Dublin Core verwenden soll, um im Bedarfsfalle weitere Datumsangaben zu machen. Da man diese aber wiederum nicht als Elemente angeben soll, bleibt nur die Verwendung mit dem Element meta. Da man auch die Art des Datums nur noch als Verfeinerung per Element meta angeben kann, kann man das auch gleich komplett mit einem Element meta machen, somit ist auch das Element date in Version 3 redundant.

Weil man natürlich nicht nur Terme von Dublin Core, sondern auch die Elemente von Dublin Core als Eigenschaften von meta verwenden kann, lassen sich alle diese Einschränkungen ohnehin leicht umgehen. Wo ein Element also nicht ausreicht, empfiehlt es sich generell, dieses vollständig durch meta-Elemente zu ersetzen und nicht nur unzureichend zu verfeinern.

Einmal abgesehen von den erforderlich zu notierenden drei Elementen von Dublin Core kann es daher pauschal einfacher sein, weitere Metainformationen gleich nur noch mit meta-Elementen zu machen.

Der Nachteil dieses Vorgehens besteht natürlich darin, daß Programme, die nur Version 2 kennen, Angaben mit meta-Elementen ignorieren werden, weil das Konzept in Version 2 ein anderes ist. Insgesamt ergibt sich hier eine zum großen Teil unnötige Rückwärtsinkompatibilität durch die Änderungen in Version 3.

Da auch bei der Angabe der Autoren und Mitarbeiter zur Angabe der Funktion bei Version auf meta zurückgegriffen werden muß, ergeben sich hier auch formale Änderungen. Quelle und Art der Autorenkürzel sind gleich, allerdings sind die Angaben unter einer anderen Adresse verfügbar, siehe etwa [MARC]. Die Notation erfolgt dann wie folgt:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
     xmlns:opf="http://www.idpf.org/2007/opf">
  <!-- ... andere Metainformationen ...-->
  <dc:creator opf:id="olaf" xml:lang="de">Dr. Olaf Hoffmann</dc:creator>
  <meta refines="#olaf" property="file-as">Dr. Hoffmann, Olaf</meta>
  <meta refines="#olaf" property="role" scheme="marc:relators">aut</meta>
</metadata>

Um eine spezifische Reihenfolge bei der Nennung der Autoren oder Mitarbeiter festzulegen, ist dann die bereits erwähnte Verfeinerungseigenschaft display-seq zu verwenden.

Verzeichnis aller Dateien

Im Wurzelelement package folgt dann nach dem Element metadata als zweites Element manifest mit dem Verzeichnis aller Dateien des Buches. Dies deckt sich mit Version 2. Unverändert bleibt ebenfalls, daß die Kindelemente von manifest Elemente item sind, mindestens eines davon ist erforderlich.

Um jedes item identifizieren zu können, ist wie gehabt ein Fragmentidentifizierer mit dem Attribut id anzugeben.
Ebenfalls wie gehabt erforderlich ist ein Attribut href, dessen Wert eine IRI ist. Referenziert wird damit eine Datei, welche zum Inhalt des Buches beiträgt.
Auch unverändert ist die erforderliche Angabe des Inhaltstyps oder Medientyps mit dem Attribut media-type.

Handelt es sich beim Medientyp nicht um einen Kernmedientyp (siehe unten), so ist per Attribut fallback auf ein anderes item zu verweisen. Ist auch dieses kein Kernmedientyp, so wird auch dies wieder auf ein anderes item verweisen. Zirkelschlüsse sind dabei unzulässig und das letzte item dieser Kette muß dann ein Kernmedientyp sein. Entsprechend ist auch vorzugehen, wenn ein item im spine referenziert wird und es sich nicht um ein Inhaltsdokument handelt. Das letzte item dieser Kette muß dann letztlich ein Inhaltsdokument sein.

Die Möglichkeit in Version 2 mittels fallback-style eine Stilvorlage anzugeben, mit welcher der Inhalt hinreichend dargestellt wird, entfällt in Version 3, womit sich eine weitere Einschränkung der Möglichkeiten gegenüber Version 2 ergibt, auch hier fällt Version 3 wieder ein gutes Stück armseliger als Version 2 aus. Allerdings ist dies wohl nicht primär den Autoren der Spezifikationen anzulasten, sondern eher den Anbietern der Darstellungsprogramme, weil diese derartig wichtige Funktionen der Version 2 nicht implementiert haben.

Neu in Version 3 ist hingegen das Attribut properties. Der Wert ist eine mit Leerzeichen separierte Liste von vordefinierten Werten oder CURIEs. Je nach referenziertem Inhalt ist das Attribut optional oder erforderlich. Jeder Listenpunkt charakterisiert eine Eigenschaft oder einen im Dokument vorhandenen Inhalt. Folgendes ist eine Liste der vordefinierten Werte:

'cover-image'
Die referenzierte Datei ist als Umschlagsbild oder Einband gedacht; nur verwendbar bei Pixelgraphikbildern oder Vektorgraphiken.
'mathml'
Diese Angabe ist exakt dann erforderlich und erlaubt, wenn ein XHTML-Dokument ein Fragment im Format MathML enthält.
'nav'
Exakt ein Eintrag muß diese Eigenschaft aufweisen. Das referenzierte Dokument stellt dann das navigierbare Inhaltsverzeichnis dar.
'remote-resources'
Diese Eigenschaft muß angegeben werden, wenn das referenzierte Dokument Verweise auf externe Ressourcen enthält.
'scripted'
Diese Eigenschaft muß angegeben werden, wenn das referenzierte Dokument Skripte oder Formulare enthält. Enthalten bezieht sich hier auch darauf, daß eingebettete Dokumente Skripte enthalten. Sofern es also für die Gesamtdarstellung einen Unterschied macht, ob Skriptinterpretation verfügbar ist oder nicht, ist diese Eigenschaft zu setzen.
'svg'
Diese Eigenschaft muß angegeben werden, wenn das referenzierte XHTML-Dokument Fragmente im Format SVG enthält. Bei eigenständigen SVG-Dateien ist die Angabe nicht notwendig.
'switch'
Diese Eigenschaft muß angegeben werden, wenn das referenzierte Dokument ein Element switch aus dem Namensraum von EPUB enthält.

Neu ist auch das Attribut media-overlay. Mit dem Attribut wird im Bedarfsfalle das item referenziert, welches zu dem item mit dem Attribut eine zu überlagernde Audio-Datei anbietet. Solche Dateien sind jeweils in eine Datei im Format SMIL zu integrieren, welche die Funktionalität zur Synchronisierung bereitstellen. Formal ergibt sich dabei allerdings das Problem, daß eigentlich alle Dateien in der SMIL-Datei referenziert werden müssen, um diese zu synchronisieren oder interaktiv damit zu agieren. In der einfachsten Variante läßt sich damit ähnlich wie bereits mit DAISY ein Hörbuch realisieren, wobei man dann zwischen der akustischen Variante und der Text-Variante wählen kann. Das Buch wird dann also nicht einfach vom Programm vorgelesen, sondern es wird unabhängig vom vorhandenen Text eine Audio-Datei abgespielt. Bei EPUB 3 wird nun im Falle der Interpretation solcher Medienüberlagerungen die Abhängigkeit so gedreht, daß die SMIL-Dateien die primären Dokumente sind und darin Fragmente aus den Inhaltsdateien referenziert werden, um sie mit Audio-Dateien zu synchronisieren. Die genaue Struktur der SMIL-Dateien wird in einem Abschnitt weiter unten erläutert. Für einen Eintrag eines Inhaltsdokumentes sieht das zum Beispiel so aus:

<item id="k1.xhtml" 
   href="k1.xhtml" 
   media-type="application/xhtml+xml" 
   media-overlay="k1.smil"/>
<item id="k1.smil" 
   href="k1.smil" 
   media-type="application/smil+xml"/>

Pro Inhaltsdokument darf es auch nur maximal eine SMIL-Datei als Medienüberlagerung geben. Diese kann natürlich viele Audio-Dateien referenzieren.

Kernmedientypen

Kernmedientypen sind Formate oder Medientypen, die von Darstellungsprogrammen für EPUB 3 interpretiert werden müssen. Eigenständige Dokumente in solchen Formaten sind sogenannte Inhaltsdokumente, diese sind immer entweder SVG-Dokumente oder XHTML-Dokumente. Alle andere Formate sind im Bedarfsfalle in solche Dokumente einzubetten.
Für Dokumente, die einen Kernmedientyp verwenden, braucht kein alternativer Inhalt bereitgestellt werden, sofern nicht anders angegeben. Für andere Formate sind immer Alternativen mit Kernmedientypen zu realisieren. Wie die Alternative bereitgestellt wird, hängt stark vom Format ab, bei Pixelgraphik ist das etwa oft alternativer Text im SVG-Dokument oder XHTML-Dokument oder aber im SVG-Dokument auch eine Repräsentation als Vektorgraphik mit Beschreibung.

Folgendes sind die Kernmedientypen:

'image/png'
Pixelgraphik, Computergraphik, PNG - Textalternative für nicht visuelle Darstellung notwendig
'image/jpeg'
Pixelgraphik, digitale Photographien, JPEG/JFIF - Textalternative für nicht visuelle Darstellung notwendig
'image/gif'
Pixelgraphik, veraltetes Format GIF, durch PNG oder SVG ersetzbar - Textalternative für nicht visuelle Darstellung notwendig
'image/svg+xml'
Vektorgraphik, SVG
'text/css'
Stilvorlage im Format CSS, bietet nur eine alternative Präsentation des Inhaltes, keine neue Information
'application/xhtml+xml'
Text im Format XHTML
'application/x-dtbncx+xml'
Das Format nur für das veraltete Inhaltsverzeichnis
'application/vnd.ms-opentype'
Schriftartendatei; eine generische Schriftfamilie ist allerdings immer als Alternative anzugeben
'application/font-woff'
Schriftartendatei; eine generische Schriftfamilie ist allerdings immer als Alternative anzugeben
'application/smil+xml'
eingeschränkt auf die in EPUB 3 beschriebene überlagernde Audio-Datei
'application/pls+xml'
Lexikon-Format für die Konversion von Text zu Sprache
'audio/mpeg'
MP3-Datei; da die Implementierung des Formates eine Lizenz erfordert, kann es allerdings für einige Darstellungsprogramme undurchführbar sein, dieser Anforderung nachzukommen, die Anforderung ist also unangemessen
'audio/mp4'
AAC-LC mit MP4-Container; da die Implementierung des Formates eine Lizenz erfordert, kann es allerdings für einige Darstellungsprogramme undurchführbar sein, dieser Anforderung nachzukommen, die Anforderung ist also unangemessen
'text/javascript' (eigentlich 'application/javascript')
Skriptsprache, Interpretation allerdings optional - die Inhalte sind immer so zu formulieren, daß sie komplett zugänglich sind, auch wenn die Interpretation von Skripten deaktiviert ist; die Skripte liefern also eher eine alternative Präsentation des ohnehin vorhandenen Inhaltes, ähnlich wie bei Stilvorlagen

Insbesondere gibt es für Video kein Format, welches notwendig zu interpretieren wäre. In dieser Hinsicht sind Autoren mit Version 3 also nicht besser dran als mit Version 2, wo dies auch nicht der Fall war. Praktisch ist es mit den Audio-Formaten ähnlich. Zwar wird die Interpretation von zweien als notwendig angegeben, was aber aufgrund von Lizenzproblemen für Anbieter von Darstellungsprogrammen so nicht umsetzbar sein muß.

Öfter wird behauptet, die Version 3 eigne sich besonders gut für sogenannte erweiterte digitale Bücher (englisch: enhanced ebooks), tatsächlich eignet sich Version 2 dafür nicht wesentlich schlechter, teilweise sogar besser. Das hängt zum Teil damit zusammen, daß einige Formate nun erforderlich interpretiert werden müssen, die zuvor nur optional waren. Ob es funktioniert hängt also mehr an den Darstellungsprogrammen als an der verwendeten EPUB-Version. Wenn es für ein Buch in Version 3 klappt, wird es so auch für Version 2 klappen, bei welcher man nur bei inhaltlich relevanten Teilen eine Alternative bereitstellen muß, die aus einem erforderlich zu interpretierenden Format besteht. Es hält einen natürlich auch bei Version 3 niemand davon ab, solche Alternativen zusätzlich anzubieten.

Reihenfolge der Inhalte

Als drittes Kindelement vom Wurzelelement package ist wie gehabt spine zu notieren. Anders als bei Version 2 ist bei Version 3 das Attribut toc nicht mehr erforderlich, kann aber nach wie vor verwendet werden, um ein item mit einer Navigationskontrolldatei (englisch: Navigation Control File for XML applications; NCX) zu referenzieren. Dies darf dann allerdings keine Dokumenttypdeklaration enthalten, weil solche bei EPUB 3 generell unerwünscht sind. Diese Navigationskontrolldatei ist zu empfehlen, um kompatibel zu alten Darstellungsprogrammen zu bleiben, die diese Datei erwarten und verwenden und nicht die in Version 3 erforderliche XHTML-Datei mit dem gleichen Zweck, die wie beschrieben bereits im item gekennzeichnet wird.

Mit dem neuen Attribut page-progression-direction kann die Lesereihenfolge für den gesamten Inhalt angegeben werden, bezogen auf die Abfolge der Zeichen in den Dokumenten. Zu bedenken ist auch hier, daß UTF-8 bereits eine normale Lesereihenfolge festlegt. Das Attribut ist also nur hilfreich, wenn gezielt davon abgewichen werden soll. Der Wert ist entweder 'ltr' für von links nach rechts, oder 'rtl' für von rechts nach links oder. 'default', bei welcher das Darstellungsprogramm die Leserichtung selbst festlegt. Von oben nach unten etwa oder umgedreht ist nicht vorgesehen.

Der Inhalt von spine besteht wie gehabt aus Elementen itemref; mindestens die Angabe eines solchen Elementes ist erforderlich. Die Reihenfolge dieser Elemente bestimmt die normale Lesereihenfolge bezogen auf die referenzierten Dokumente.

Mit dem erforderlichen Attribut idref wird ein item aus dem manifest referenziert, welches entweder selbst ein Inhaltsdokument ist oder für welches in einer Kette von Alternativen letztlich ein Inhaltsdokument als Alternative verfügbar ist.

Ebenfalls aus Version 2 unverändert übernommen ist das Attribut linear, mit welchem bestimmt wird, ob das referenzierte Dokument zur linearen Lesereihenfolge gehört oder nicht. Bei fehlendem Attribut oder beim Wert 'yes' gehört es zur linearen Lesereihenfolge, beim Wert 'no' nicht.

Neu in Version 3 ist hingegen auch hier das Attribut properties. Der Wert ist eine mit Leerzeichen separierte Liste von vordefinierten Werten oder CURIEs. Je nach referenziertem Inhalt ist das Attribut optional oder erforderlich. Jeder Listenpunkt charakterisiert eine Eigenschaft oder einen im Dokument vorhandenen Inhalt. Die vordefinierten Werte beziehen sich darauf, ob bei einer mehrspaltigen Darstellung der Inhalt des Dokumentes links oder rechts beginnt. Es darf daher nur maximal einer dieser beiden Werte notiert werden:

'page-spread-left'
links
'page-spread-right'
rechts

In EPUB 3.0.1 wird ferner klargestellt, daß auch Inhaltsdokumente aufgeführt sein müssen, auf welche lediglich in anderen Inhaltsdokumenten verwiesen wird. Damit sind direkte Verweise gemeint, einschließlich solche in möglichen verweissensitiven Graphiken. Auf Verweise in SVG-Dokumenten wird dabei nicht näher eingegangen, sinngemäß gehören diese aber wohl zu der gemeinten Gruppe.

In der Praxis ignorieren viele Darstellungsprogramme die Angabe zu linear 'no', stellen solche Inhalte entweder in der angegebenen Reihenfolge dar oder im Anschluß an die als linear angegebenen Dokumente. Gemäß EPUB ist dieses Verhalten sogar zulässig. Zusammen mit der Forderung, alle referenzierten Inhaltsdokumenente im spine aufzuführen, sabotiert dies eine sinnvolle Funktion für nicht-lineare Bücher.

Problematisch ist diese Forderung insbesondere für Bücher mit einer nicht-linearen Lesereihenfolge, etwa wenn Leser zwischen alternativen Fortsetzungen einer Geschichte selbst entscheiden sollen oder wenn eine labyrinthartige Inhaltsstruktur vorliegt, welche gar keine vorgebbare Reihenfolge hat. Technisch sind solche Inhalte bei digitalen Büchern natürlich eigentlich kein Problem. Allein EPUB selbst macht sie zum Problem, weil sich die Autoren der Empfehlung offenbar nicht von der Vorstellung klassischer, gedruckter Bücher lösen können, bei denen ja bekannt ist, daß nicht-lineare Inhalte für diese problematisch sind, weil bei solchen Büchern der Inhalt auf Seiten gedruckt wird, die zusammengebunden werden und an einem Buchrücken befestigt werden. EPUB vermag sich leider nicht von dieser Vorstellung gedruckter Bücher lösen und vertut hier eine große Chance, wirklich neue Typen von Büchern zu ermöglichen, die mit gedruckten Büchern nie gut umgesetzt werden konnten. Dies Problem trifft auf Version 2 und 3 zu, daß die Einschränkung in Version 3.0 nicht explizit genannt wurde, ist entweder ein Versehen oder aber der Rückzieher in Version 3.0.1 zeigt nur noch deutlicher, daß hier der Mut fehlt, mit dem Format die Möglichkeiten digitaler Medien wirklich zu nutzen.

Autoren von nicht-linearen Büchern können hier bestenfalls improvisieren, indem sie zum Beispiel die nicht-linearen Inhalte in einer zufälligen Reihenfolge im spine notieren oder aber aber auch vor und nach jedem nicht-linearen Dokument im spine zahlreiche weitere nicht-lineare Dokumente ohne Inhalt einfügen, oder nur mit solchem Navigationsinhalt, welcher dem Leser hilft, unter den sinnvollen Alternativen eines nicht-linearen Buches auszuwählen, statt durch den untauglichen, automatischen Mechanismus des Darstellungsprogrammes zu an dieser Stelle falschen Inhalten zu gelangen.

Ebenfalls neu in Version 3.0.1: Abweichend zur globalen Metainformation zur Art der Darstellung kann bei jedem itemref von spine die vom Autor bevorzugte Darstellung angegeben werden, wobei diese dann natürlich die globale Einstellung überschreibt. Dazu wird als ein Listenwert von properties eine Darstellungsmöglichkeit angegeben, die der jeweiligen Bedeutung der globalen Einstellung entspricht:

'rendition:flow-auto'
überläßt dem Darstellungsprogramm die Art der Darstellung
'rendition:flow-paginated'
für automatische Seiteneinteilung
'rendition:flow-scrolled-continuous'
für eine rollbare Darstellung statt einer Seiteneinteilung für das gesamte Buch
'rendition:flow-scrolled-doc'
für eine Seiteneinteilung je Einzeldokument, welches wiederum rollbar darstellbar ist

Unklar dabei bleibt allerdings, wie sich bei einem einzelnen Dokument 'rendition:flow-scrolled-continuous' von 'rendition:flow-scrolled-doc' unterscheidet.

Auch neu in Version 3.0.1: Mit der properties mit dem Wert 'rendition:align-x-center' kann angegeben werden, daß der Container mit dem Inhalt eines itemref zentriert dargestellt werden soll. Es geht also nicht um das Zentrieren des Inhaltes selbst, sondern des Containers relativ zum verfügbaren Darstellungsbereich, falls dieser nicht ohnehin komplett genutzt wird. Eigentlich sollte dies ja komplett mit CSS zu erledigen sein, mag aber sein, daß man hiermit Verhalten beeinflussen können soll, welches jenseits der Einflußmöglichkeiten von CSS liegt. Generell wird auch empfohlen, CSS zu verwenden, so weit dies für den gewünschten Zweck möglich ist.

Einstiegspunkte

Wie in Version 2 können mit guide Einstiegspunkte ins Buch angegeben werden. Das Element ist unverändert. Es ist allerdings als veraltet gekennzeichnet. Bereits für Version 2 ist die Interpretation durch Darstellungsprogramme eher dürftig, als Autor kann man sich die Verwendung also sparen.

Bindungen

Neu ist die Möglichkeit, Bindungen von optionalen Formaten an Skriptdateien anzugeben. Dazu dient das Element bindings, welches als letztes Kindelement von package notiert werden kann. Wenn ein optionales Format im Buch nicht interpretiert werden kann, kann über das Skript die Funktion des Formates simuliert werden. Allerdings ist es auch nicht erforderlich, daß Skripte interpretiert werden, von daher ist der Nutzen dieses Elementes sehr begrenzt, weil sich ein Autor natürlich nicht darauf verlassen kann, daß solch eine Bindung brauchbar interpretiert wird. Attribute hat das Element nicht. Der Inhalt besteht aus Elementen mediaType. Mindestens eines ist zu notieren.

Anwendbar ist eine solche Bindung für XHTML-Dokumente und dort für Medien, die per object eingebunden werden. Bereits in XHTML können Alternativen notiert werden, falls ein Format nicht interpretiert wird. Darüber hinaus wird mit einer Bindung ein weiteres XHTML-Dokument angegeben, welches als Alternative für ein nicht interpretiertes Format verwendet wird. Ein solches XHTML-Dokument enthält dann typisch ein Skript, welches irgendwelchen Ersatz für das gesamte Format liefern soll. Erst sollen solche Bindungen geprüft werden, dann der alternative Inhalt des Elementes object, falls keine Bindung verfügbar ist.

Bei dem object wird mit dem Attribut data die einzubindende Datei referenziert und mit type der Medientyp angegeben. Diese Angaben werden dann mit den Parametern src und type der Bindung übergeben.

Das Kindelement mediaType von bindings hat die erforderlichen Attribute media-type und handler. Mit media-type wird als Wert der Medientyp für die Bindung angegeben. Mit handler wird das item eines XHTML-Dokumentes referenziert, mit welchem Inhalte im angegebenen Format alternativ behandelt werden können. Dabei darf ein Medientyp nur maximal einmal in bindings genannt werden.

Sammlungen

In Version 3.0.1 können auf das optionale bindings Elemente collection in beliebiger Anzahl folgen. Ein solches Dokument dient der Kennzeichnung unmittelbar zusammengehöriger Inhalte, die lediglich aus technischen Gründen auf verschiedene Dateien verteilt wurden. Etwa weil sehr einfache Darstellungsprogramme Probleme mit der Präsentation von großen Dateien haben könnten, die einige Megabyte umfassen, kann es zumindest bei XHTML sinnvoll sein, sofern keine sonstige weitere sinnvolle inhaltliche Strukturierung vorliegt, eine Aufteilung in Einzeldokumente nach Bytes oder einer bestimmten Zahl von Absätzen vorzunehmen, gleichzeitig aber zu kennzeichnen, daß es sich dabei nicht um eine Aufteilung handelt, die bei einer Präsentation des Inhaltes oder der Konversion in ein anderes Format berücksichtigt werden soll. Mit collection kann diese semantische Information angegeben werden, die ansonsten keine weiteren Folgen für die Interpretation des eigentlichen Inhaltes hat. Für Darstellungsprogramme ist die Interpretation optional.

Das Attribut xml:lang kann für die Angabe der verwendeten Sprache verwendet werden, sinnvoll, wenn diese von der für package abweicht.

Ebenfalls kann mittels des Attributes dir die normale Leserichtung angegeben werden, also entweder 'ltr' für von links nach rechts, oder 'rtl' für von rechts nach links. Von oben nach unten etwa oder umgedreht ist nicht vorgesehen.

Mit dem Attribut id kann ein Fragmentidentifizierer notiert werden.

Mit dem erforderlichen Attribut role wird die Funktion des Elementes notiert. Der Wert ist entweder eine IRI, welche eine anderweitig definierte Rolle definiert oder eine Zeichenkette mit vorgegebener Bedeutung. Diese kann nur vom IDPF definiert werden, was aber zum Erscheinungsdatum von Version 3.0.1 am 2014-06-26 noch nicht geschehen ist.

Der Inhalt von collection kann optional ein Element metadata sein, optional gefolgt von entweder nur mindestens einem Element collection oder aber keinem oder mehreren Elementen collection gefolgt von mindestens einem Element link. Entsprechend können durch Verschachtelungen folglich Unter-Sammlungen notiert werden.

metadata in collection entspricht dem vom package mit ein paar wenigen Abweichungen:

link in collection entspricht dem vom metadata mit ein paar wenigen Abweichungen:

Allerdings muß link immer einen Teil der Sammlung referenzieren.

Komplettes Beispiel

<?xml version="1.0" encoding="UTF-8" ?>
<package version="3.0"
    xml:lang="de"
    unique-identifier="id"
    xmlns="http://www.idpf.org/2007/opf" 
    xmlns:opf="http://www.idpf.org/2007/opf">
  <metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
<!-- Eindeutige Buchidentifikation, hier mit einer UUID -->
    <dc:identifier opf:id="id">a3a2a8bb-71bf-41b7-9083-5ffed2775899</dc:identifier>
    <meta property="identifier-type" refines="#id">UUID</meta>
<!-- Angabe zur letzten Änderung -->
    <meta property="dcterms:modified">2013-09-13T17:07:34Z</meta> 
<!-- Weitere Zeitangaben -->
    <meta property="dcterms:created">2013-05/09</meta>
    <meta property="dcterms:dateAccepted">2013-09-03</meta>    
<!-- Angabe zur hauptsächlich verwendeten Sprache -->
    <dc:language>de</dc:language>
<!-- Der Buchtitel -->
    <dc:title opf:id="id_title">Verhängnisvolle Verstrickung</dc:title>
    <meta refines="#id_title" property="title-type">main</meta>
    <meta refines="#id_title" property="display-seq">1</meta>
<!-- Der Untertitel -->
    <dc:title  opf:id="id_sub">Ein Krimi-Schocker in der hannöverschen Strickgraffiti-Subkultur</dc:title>
    <meta refines="#id_sub" property="title-type">subtitle</meta>
    <meta refines="#id_title" property="display-seq">2</meta>
<!-- Beschreibung -->    
    <dc:description>Ein grauenhaftes Verbrechen überschattet die Kunstszene in Hannover.
    Am Bahnhofs-Ernst-August wurde der Strickgraffiti-Außenseiter 
    Rainer Wahn am eigenen Gestrickten aufgehängt. 
    Kommissarin Mimmi Kri ermittelt im den Untiefen der Strickgraffiti-Subkultur 
    und fördert aus einem Sumpf von Verstrickungen und Häkeleien Unglaubliches hervor.
    </dc:description>    
<!-- Autoren -->
    <dc:creator opf:id="funda">Funda Mental</dc:creator>    
      <meta refines="#funda" property="file-as">Mental, Funda</meta>
      <meta refines="#funda" property="role" scheme="marc:relators">edt</meta>
      <meta refines="#funda" property="display-seq">2</meta> 
    <dc:creator opf:id="klara">Klara Fall</dc:creator>
      <meta refines="#klara" property="file-as">Prof. Dr. Fall, Klara</meta>
      <meta refines="#klara" property="role" scheme="marc:relators">aut</meta>
      <meta refines="#klara" property="display-seq">1</meta>  
<!-- Mitarbeiter -->
    <dc:contibutor opf:id="klaus">Klaus Trophob</dc:contributor>
      <meta refines="#klaus" property="file-as">Prof. Dr. Trophob, Klaus</meta>
      <meta refines="#klaus" property="role" scheme="marc:relators">lyr</meta>
      <meta refines="#klaus" property="role" scheme="marc:relators">pht</meta>
      <meta refines="#klaus" property="role" scheme="marc:relators">exp</meta>
      <meta refines="#klaus" property="display-seq">1</meta>        
    <dc:contibutor opf:id="norma">Norma Tief</dc:contributor>
      <meta refines="#norma" property="file-as">Tief, Norma</meta>
      <meta refines="#norma" property="role" scheme="marc:relators">aft</meta>
      <meta refines="#norma" property="role" scheme="marc:relators">aui</meta>
      <meta refines="#norma" property="display-seq">2</meta>   
<!-- Verleger, Verlag -->
    <dc:publisher>Hanno-Verlach am Glocksee</dc:publisher>
<!-- Inhaltstyp -->
    <dc:format>application/epub+zip</dc:format>  
<!-- Buchtyp -->
    <meta property="dcterms:type">Collection</meta>
    <meta property="dcterms:type">Text</meta>
    <meta property="dcterms:type">StillImage</meta>
<!-- Thema, Bezug -->
    <dc:subject>Krimi</dc:subject>
    <dc:subject>Mimmi Kri</dc:subject>
    <dc:subject>Kunst</dc:subject>
    <dc:subject>Strickgraffiti</dc:subject>
    <dc:subject>Öffentliche Kunst</dc:subject>
<!-- Räumlicher oder auch zeitlicher Bezug -->
    <dc:coverage xml:lang="de">Hannover, Deutschland</dc:coverage>
    <dc:coverage>52.37°, 9.74°</dc:coverage>
  </metadata>
  <manifest>
    <item id="ncx"
      href="toc.ncx" 
      media-type="application/x-dtbncx+xml"/>  
    <item id="nav"  
      properties="nav"
      href="nav.xhtml"
      media-type="application/xhtml+xml" />

    <item id="meta" 
      href="meta.xhtml"
      media-type="application/xhtml+xml" />      
      
    <item id="vorwort" 
      href="vorwort.xhtml"
      media-type="application/xhtml+xml" />
    <item id="nachwort"
      href="nachwort.xhtml"
      media-type="application/xhtml+xml" />  
  
    <item id="k1" 
      href="k1.xhtml"
      media-type="application/xhtml+xml" />
    <item id="k2" 
      href="k2.xhtml"
      media-type="application/xhtml+xml" />  
    <item id="k3" 
      href="k3.xhtml"
      media-type="application/xhtml+xml" />
    <item id="k4" 
      href="k4.xhtml"
      media-type="application/xhtml+xml" />  
    <item id="k5" 
      href="k5.xhtml"
      media-type="application/xhtml+xml" />
    <item id="k6" 
      href="k6.xhtml"
      media-type="application/xhtml+xml" />  
    <item id="k7" 
      href="k7.xhtml"
      media-type="application/xhtml+xml" />
    <item id="k8" 
      href="k8.xhtml"
      media-type="application/xhtml+xml" />
    <!-- etc -->
           
    <item id="einband.svg"  
      properties="cover-image"
      href="einband.svg"  
      media-type="image/svg+xml"/>
    <item id="raineramernstaugust.jpg"  
      href="raineramernstaugust.jpg"  
      media-type="image/jpeg"/>
    <item id="verstrickt.jpg"  
      href="verstrickt.jpg"  
      media-type="image/jpeg"/>
    <item id="MimmiKri.jpg"  
      href="MimmiKri.jpg"  
      media-type="image/jpeg"/>          
    <!-- etc --> 
    
    <item id="KlaraFall.jpg"  
      href="KlaraFall.jpg"  
      media-type="image/jpeg"/>      

  </manifest>
  <spine  toc="ncx">
    <!-- ... Reihenfolge der Inhaltsdateien-->
     <itemref idref="einband.svg"/>
     <itemref idref="meta"/>
     <itemref idref="vorwort"/>
     <itemref idref="nav"/>
     <itemref idref="k1"/>
     <itemref idref="k2"/>
     <itemref idref="k3"/>
     <itemref idref="k4"/>
     <itemref idref="k5"/>
     <itemref idref="k6"/>
     <itemref idref="k7"/>
     <itemref idref="k8"/>
     <!-- etc -->
     <itemref idref="nachwort"/>
  </spine>
</package>

Inhaltsdokumente

Allgemeine Inhaltsdokumente für EPUB 3 sind spezielle SVG-Dokumente oder spezielle XHTML-Dokumente, wobei diese Empfehlungen teilweise eingeschränkt werden, aber die Möglichkeiten von XHTML-Dokumenten auch durch wenige Elemente und Attribute aus dem Namensraum von EPUB 'http://www.idpf.org/2007/ops' erweitert werden können.

SVG

SVG-Dokumente sind im Umfang von Version 1.1 mit wenigen, aber wesentlichen Einschränkungen als eigenständige Inhaltsdokumente erlaubt, aber auch wie bei Version 2 als eingebettete Dokumente oder Inseln in einem XHTML-Dokument. Leider immer noch ausgeschlossen ist der Teil von SVG 1.1 über deklarative Animation und deklarative Interaktion - und dies im eindeutigen Widerspruch zur eigenen Forderung, daß Autoren deklarative Techniken in EPUB nutzen sollen, statt etwa Skripte zu verwenden, deren Interpretation allerdings optional zulässig ist. Autoren müssen dann natürlich immer sicherstellen, daß der eigentliche Dokumentinhalt auch ohne Interpretation der Skripte komplett verfügbar ist, die Skripte ändern also allenfalls etwas an der Präsentation dieses Inhaltes. Der Inhalt von foreignObject darf nur aus XHTML bestehen und das Attribut requiredExtensions darf nur mit dem Wert 'http://www.idpf.org/2007/ops' verwendet werden. Ferner wird der Inhalt von title einschränkt auf einfachen Text oder Phrasenelemente von XHTML, wobei ohnehin generell zu empfehlen ist, in title nur einfachen Text zu notieren und längere Ausführungen etwa in desc unterzubringen, für welches es keine Einschränkungen gibt.

Eine ausführliche Anleitung zu SVG ist zum Beispiel in einem Wiki-Buch zu finden, von dem der Autor dieses Artikels ebenfalls der Hauptautor ist, daher wird hier nicht näher auf SVG eingegangen [WSVG].

XHTML

Wie bereits erwähnt, wird neben SVG XHTML für Inhaltsdokumente verwendet, wobei letzteres bei Büchern mit klassischem Schwerpunkt Text den Hauptinhalt darstellen wird. EPUB 3 bezieht sich dabei auf die XML-Variante von HTML5, für welches die Empfehlung des W3C erst am 2014-10-28 veröffentlicht wurde, also Jahre nach der Empfehlung EPUB 3. Die später erschienene kann für die frühere also nicht wirklich normativ sein. Welcher Arbeitsentwurf dies wäre, ist allerdings in EPUB 3 auch nicht festgelegt.

Der Schwerpunkt der schließlich veröffentlichten Empfehlung von HTML5 ist zudem eine Variante mit eigener Syntax, die inkompatibel sowohl zum alten HTML ist, als auch zu XML. In speziellen Abschnitten wird allerdings darauf eingegangen, wie diese Entwürfe auch als XHTML umgesetzt werden können, eine wesentlich einfachere Variante, bei welcher viele Dinge der sehr umfangreichen Empfehlung einfach als unzutreffend wegfallen, weil die betrachteten Situationen bei XHTML-Dokumenten gar nicht eintreten können.

HTML5 erlaubt zudem explizit, den Dokumenttyp etwa von XHTML 1.1 zu verwenden. Diese Variante von XHTML wird ja auch bereits in EPUB 2 verwendet und wenn man bereits Inhalt in dieser Variante hat, Inhalt veröffentlichen möchte, der einer definierten Empfehlung folgt oder auch nur einer definierten Version von XHTML, so ist wie gehabt XHTML 1.1 eine Möglichkeit und man muß sich als Autor nicht unbedingt um die Empfehlung zu HTML5 kümmern, die zudem Vieles enthält, was für XHTML-Dokumente ohnehin nicht zutrifft. Allerdings liefert die Empfehlung zu HTML5 auch einen bescheidenen Satz neuer, semantisch relevanter Elemente, die also in XHTML 1.1 so nicht verfügbar sind. Allerdings ist HTML5 nicht auf Bücher oder allgemein klassische Texte hin ausgerichtet, sondern verstärkt auf komplexe Netz-Veröffentlichungen, wie sie mit den gängigen Darstellungsprogrammen angesehen werden. Von daher ist HTML5 nach Meinung der betreuenden Arbeitsgruppe auch keine Textauszeichnungssprache wie die anderen Versionen von (X)HTML, sondern ein Sammelsurium von Anwendungen für Netz-Veröffentlichungen. Auch von daher ist HTML5 nur sehr bedingt für das Schreiben von Büchern geeignet oder dafür optimiert. Die Elementkollektion ist einfach unzureichend, allerdings bereits etwas umfangreicher als bei XHTML 1.1.

Um die Mängel und Lücken in der Elementkollektion von HTML5 zu kompensieren, führt EPUB 3 wenige Attribute und Elemente im eigenen Namensraum als Ergänzung ein. Ebenfalls verfügbar ist ein dazugehöriger Satz von Ausdrücken, die ein semantisches Vokabular bereitstellen, welches den Darstellungsprogrammen für EPUB 3 bekannt sein muß. Dies kann wiederum auch durch Verwendung eigener Vokabularien erweitert werden, um etwa wieder das Niveau von DAISY, beziehungsweise DTB zu erreichen oder noch darüber hinaus zu gehen. In der Möglichkeit, eigene Vokabularien innerhalb der normalen XHTML-Dokumente zu verwenden, liegt eine große Stärke von EPUB 3, denn in Version 2 mußte man noch mehr oder weniger Dokumente in Formate verwenden, die nicht notwendig interpretierbar waren und dazu dann noch Alternativen dazu in den Inhaltsformaten.

Unklar bleibt in Version 3.0, ob die für HTML5 bereits ebenfalls verfügbaren Erweiterungen ebenfalls nutzbar sind, die es erlauben, RDFa [HRDFa] zu verwenden. Im Bedarfsfalle sollte man es einfach tun. Immerhin gibt es für die Einbettung von RDFa in HTML5 bereits eine Empfehlung des W3C noch vor jener für HTML5 selbst.
Version 3.0.1 erlaubt explizit die Verwendung von RDFa und sogar auch der sogenannten Microdata, etwas, was einmal in einem frühen Arbeitsentwurf von HTML5 zu finden war, dann dort entfernt wurde und schließlich (oder einstweilen?) als unverbindliche Note gescheitert ist. Von daher ist dringend zu empfehlen, das vom W3C empfohlene RDFa stattdessen zu verwenden, welches ohnehin besser durchdacht ist und breiter einsetzbar. Die Interpretation durch das Darstellungsprogramm ist in beiden Fällen optional. Aufgrund der Verwendung in Attributform stört die Anwesenheit solcher Informationen ohnehin die Interpretation des Basisinhaltes nicht, Programme, die die semantischen Zusatzinformationen nicht kennen, werden also nicht ausgeschlossen.
Ferner können auch Attribute aus anderen Namenräumen notiert werden, dann immer mit korrekter Namensraumangabe. Eine Interpretation ist natürlich ebenfalls optional und Autoren müssen den Inhalt so gestalten, daß eine Interpretation nicht die Bedeutung des Inhaltes ändert.

Eine weitere kleine Ergänzung in Version 3.0.1 ist, daß das Attribut aria-describedat von WAI-ARIA 1.1 bei jedem XHTML-Element verwendet werden kann, um eine genauere Beschreibung der Bedeutung eines Elementes oder eine Textalternative oder Hilfe anzugeben. Der Wert ist eine IRI zu einem Dokument(fragment) mit der Beschreibung. Die Interpretation durch Darstellungsprogramme ist auch hier optional und es ist zu bedenken, daß dieses Attribut zum Zeitpunkt der Veröffentlichung von Version 3.0.1 erst im Stadium eines Arbeitsentwurfes ist, also noch keinen Empfehlungstatus hatte. Erst am 2014-03-20 hat WAI-ARIA den Status einer Empfehlung erreicht.
Insgesamt eignet sich das Attribut also sicher nicht, um damit Inhalte barrierefrei zugänglich zu machen, dies ist von den Autoren unabhängig davon zu gewährleisten - womit das Attribut dann in den allermeisten Fällen ohnehin redundant sein dürfte.

Die Beurteilung, was nun laut der HTML5-Empfehlung richtig ist oder nicht, wird auch dadurch erschwert, daß es kein formales Schema gibt, welches diese Variante automatisch zuverlässig prüfbar macht. Maßgeblich ist im Zweifelsfalle ohnehin die Prosa der Empfehlung. Es gibt allerdings beim W3C einen experimentellen Validator, welcher Hinweise darauf liefern kann, ob es Probleme mit Dokumenten gibt, wobei der Validator aber bei dieser Version noch weniger als der Validator für die strikteren XHTML-Versionen längst nicht alles als richtig erkennt, was zulässig ist. Zudem ist der experimentelle Validator nicht auf XML-Syntax umschaltbar, prüft also allenfalls den für EPUB 3 nicht zutreffenden Sprachendialekt der Markierungssuppe, der speziell für HTML5 erfunden wurde.

Eine grobe Übersicht über XHTML im Rahmen von HTML5-Arbeitsentwürfen

EPUB-Erweiterungen zu XHTML

Während in Version 2 im Bedarfsfalle Elemente aus anderen XML-Formaten verwendet werden können, um etwa semantische Defizite von XHTML auszugleichen, dienen dazu in Version 3 vorrangig spezielle Attribute. Aber auch das bereits aus Version 2 bekannte Element switch ist noch verfügbar. Diese Erweiterungen erfolgen jeweils im Namensraum 'http://www.idpf.org/2007/ops', der jeweils korrekt anzugeben ist, insbesondere also bei den Attributen per Präfix. Zum Beispiel kann dafür im Wurzelelement ein Präfix definiert werden, welches dann für das gesamte Dokument gilt:
xmlns:epub='http://www.idpf.org/2007/ops'. Das Präfix 'epub' wird in der Empfehlung verwendet, aber der Autor kann das natürlich beliebig nennen, geläufig wäre etwa auch 'ops'.

Attribut type

Mit dem Attribut type kann die semantische Bedeutung eines Elementes verfeinert werden. Diese Bedeutung darf also nicht der Bedeutung des Elementes widersprechen, sondern sie nur genauer eingrenzen. Im Zweifelsfalle sind also div oder span zu verwenden, wenn es keine passenderen Elemente gibt. Der Wert des Attributes stammt entweder aus einem vordefinierten Vokabularium [EVoc] von EPUB oder ist eine CURIE. Das Vokabularium wird unabhängig von den Versionen von EPUB erweitert, was in den nächsten Absätzen aufgeführt ist, umfaßt den Stand von Version 3.0.

Zu XHTML gibt es auch noch ein eigenes Vokabularium [HVoc], welches dann mit Präfix als CURIE verwendbar ist.

Sowohl das eine als das andere Vokabularium weist grobe Lücken hinsichtlich dessen auf, was man in Sachen Literatur für Strukturen kennt. Zum Beispiel hinsichtlich Gedichte oder Liedtexte gibt es eine komplette Fehlanzeige. Da inzwischen auch ein spezielles XHTML-Element für Dialoge erst gestrichen und dann zu etwas ganz anderem umgewandelt wurde, gibt es auch keine Möglichkeit, Dialoge etwa in Theaterstücken oder Gesprächen ordentlich auszuzeichnen und zu kennzeichnen. Wer also hinsichtlich Literatur Vokabeln sucht, aber in diesen Vokabularien nichts findet, der kommt eventuell mit LML [LML] weiter.

Im Folgenden verwendete Bezeichnungen für Gruppen von Elementen: Gruppierungselemente (p, hr, pre, blockquote, ol, ul, li, dl, dt, dd, figure, figcaption, div, main) und Abschnittselemente (article, aside, nav, section)

Das vordefinierte Vokabular richtet sich entsprechend danach, für welche Elemente das Attribut notiert wird.

Für Teile von Dokumenten oder Büchern, anwendbar auf die Elemente body und section:

'cover'
Bucheinband, Titelseite
'frontmatter'
Teile vor dem eigentlichen Inhalt wie Inhaltsverzeichnis, Widmung etc
'bodymatter'
Haupteil des Buches, eigentlicher Inhalt
'backmatter'
Teile nach dem eigentlichen Inhalt wie Index, Anhang etc

Für Buchabschnitte, anwendbar auf die Elemente body und section:

'volume'
Komponente einer Kollektion
'part'
Teil, meist mehrere Kapitel beinhaltend
'chapter'
Kapitel
'subchapter'
Unterkapitel
'division'
Abschnitt (eines Unterkapitels)

Für Bestandteile des Hauptteils, anwendbar auf das Element section und andere Gruppierungselemente:

'afterword'
Nachwort
'conclusion'
Zusammenfassung
'epigraph'
Epigraph, Motto, einleitendes Zitat
'epilogue'
Nachwort, Zusammenfassung der Ereignisse nach der Handlung
'foreword'
Vorwort
'introduction'
Einführung
'notice'
Anmerkung, Notiz
'preamble'
Beschreibende Einleitung, Kurzzusammenfassung
'preface'
Vorrede, Einleitung des Autors
'prologue'
Prolog, Hintergrund der Handlung oder Zusammenfassung der Ereignisse vor der Handlung
'warning'
Warnung

Für Abschnitte, die vorrangig der Referenzierung dienen (für Abschnittselemente):

'appendix'
Anhang
'colophon'
Kolophon, Information zum Buch als Produkt
'index'
Index
'landmarks'
Zentrale Abschnitte eines Werkes
'loi'
Liste von Illustrationen, Graphiken, Bildern
'lot'
Liste aller Tabellen eines Werkes
'toc'
Inhaltsverzeichnis

Für Glossare, Wörterverzeichnisse (dl, dt, dd, Abschnittselemente):

'glossary'
Glossar, Wörterverzeichnis (handelt es sich um ein dl, werden die folgenden Eigenschaften für dt und dd impliziert)
'glossterm'
Zu definierender Term eines Glossareintrags, erforderliches Elternelement muß die Eigenschaft 'glossary' aufweisen
'glossdef'
Definierender Teil eines Glossareintrags, erforderliches Elternelement muß die Eigenschaft 'glossary' aufweisen

Für Literaturverzeichnisse:

'bibliography'
Literaturverzeichnis (für Abschnittselemente)
'biblioentry'
Eintrag eines Literaturverzeichnisses (für Gruppierungselemente)

Typische Bestandteile von 'frontmatter':

'acknowledgments'
Danksagung (für section und Gruppierungselemente)
'contributors'
Mitarbeiter (für section und Gruppierungselemente)
'copyright-page'
Urheberrechtsangaben (für section und Gruppierungselemente)
'dedication'
Widmung (für section und Gruppierungselemente)
'errata'
Fehlerverzeichnis (für section, aside, Gruppierungselemente)
'halftitlepage'
Rückseite nach der Titelseite (für section und Gruppierungselemente)
'imprimatur'
Druckerlaubnis (für section und Gruppierungselemente)
'imprint'
Impressum (für section und Gruppierungselemente)
'other-credits'
Spezieller Dank für vorherige Veröffentlichungen, Abbildungen, Erlaubnis für Zitate etc (für section und Gruppierungselemente)
'titlepage'
Titelseite (für section und Gruppierungselemente)

Für ergänzende Inhalte:

'annotation'
Anmerkung oder Kommentar (für aside und Phrasenelemente)
'help'
Hilfen zum Inhalt (für aside und Phrasenelemente)
'marginalia'
Randbemerkung (für aside und Phrasenelemente)
'practice'
Übungsbeispiel (für aside)
'sidebar'
Vom sonstigen Inhalt deutlich abgesetzte Zusatzinformationen in eigener Box (für aside)

Für Stichpunkte, Stichwörter, Notizen:

'note'
Notiz, Anmerkung wie etwa eine Fußnote, vom Haupttext aus referenziert, typisch am Ende der Seite oder des Dokumentes (für aside)
'footnote'
Fußnote, vom Haupttext aus referenziert, typisch am Ende der Seite oder des Dokumentes (für aside)
'rearnote'
Anmerkung, am Ende des Werkes angeordnet (für aside)
'footnotes'
Gruppierung für Fußnoten (für Abschnittselemente)
'rearnotes'
Gruppierung für Anmerkungen, am Ende des Werkes angeordnet (für Abschnittselemente)

Überschriften:

'bridgehead'
Brückenkopf - Überschrift außerhalb der normalen Dokumentstruktur, keine Einschränkung auf spezielle Elemente, typisch aber p, div oder span

Titel (für h1, h2, h3, h4, h5, h6, hgroup):

'title'
Titel eines Werkes
'halftitle'
Titelangabe direkt vor dem Text eines Werkes
'fulltitle'
Kompletter Buchtitel
'subtitle'
Untertitel, alternativer Titel
'covertitle'
Titel auf dem Einband

Strukturen im laufenden Text für Phrasenelemente:

'concluding-sentence'
Zusammenfassender Satz eines Absatzes
'keyword'
Schlüsselwort
'topic-sentence'
Einleitender zusammenfassender Satz eines Absatzes

Verweise, für Element a:

'annoref'
Verweis auf einen Kommentar, korreliert mit 'annotation'
'noteref'
Verweis auf eine Notiz, korreliert mit 'note', 'footnote', 'rearnote'

Seitennumerierung, Paginierung bei Medien mit fester Seiteneinteilung:

'page-list'
Eine Liste mit Verweisen zu einzelnen Seiten(umbrüchen), für Abschnittselemente
'pagebreak'
Separator an einem Seitenende (keine Einschränkung auf spezielle Elemente)

Tabellen und Listen (nicht für XHTML-Elemente, sondern für Elemente aus dem Namensraum von SMIL: seq oder par):

'table'
Tabelle
'table-row'
Tabellenzeile
'table-cell'
Tabellenzelle
'list'
Liste
'list-item'
Listenpunkt

Attribut prefix

Das bereits für das OPF-Dokument definierte Attribut prefix kann mit gleicher Funktion auch bei XHTML-Elementen verwendet werden. Hier ist allerdings ein Präfix für den Namensraum von EPUB/OPS 'http://www.idpf.org/2007/ops' zu verwenden, nicht der von OPF. Um die semantiche Funktion von Elementen per Attribut type aus dem vorherigen Abschnitt zu kennzeichnen, könnte man etwa Präfixe für das Vokabularium von XHTML und LML zusätzlich verfügbar machen wollen. Das könnte etwa so aussehen:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ops="http://www.idpf.org/2007/ops"
      xml:lang="de"
      ops:prefix="h: http://www.w3.org/1999/xhtml/vocab#
                  l: http://purl.oclc.org/net/hoffmann/lml/#">
      <!-- ... -->

Verwendet werden die Vokabluarien dann zum Beispiel wie folgt:

<ul ops:type="h:toolbar"> <!-- ... --> </ul>

Sinngemäß können etwa durch Einführung eines Präfixes für Dublin-Core-Terme auch diese verwendet werden, also zum Beispiel um den Mangel zu beheben, daß HTML5 es selbst nicht ermöglicht anzugeben, welche Version von (X)HTML verwendet wird. Ein Präfix für Dublin-Core-Terme kann oben einfach angefügt werden, dann schreibt man also:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ops="http://www.idpf.org/2007/ops"
      xml:lang="de"
      ops:prefix="h: http://www.w3.org/1999/xhtml/vocab#
                  l: http://purl.oclc.org/net/hoffmann/lml/#
                  t: http://purl.org/dc/terms/">
      <!-- ... -->

Im Kopf der (X)HTML-Datei fügt man dann zum Beispiel folgende Verweise ein (für den Arbeitsentwurf vom 2013-08-06) und für Inhaltsdokumente von EPUB 3.0 (Empfehlung vom 2011-10-11):

<link rel="profile" 
  ops:type="t:conformsTo" 
  href="http://www.w3.org/TR/2013/CR-html5-20130806/" />
<link rel="profile" 
  ops:type="t:conformsTo" 
  href="http://www.idpf.org/epub/30/spec/epub30-contentdocs-20111011.html" />

Ganz sauber ist die Versionsangabe so allerdings nicht, weil sie eigentlich mit einem Attribut von (X)HTML erfolgen sollte, was aber in den Arbeitsentwürfen für HTML5 leider mutwillig entsorgt wurde, um es Autoren zu erschweren, Dokumente mit definiertem Inhalt zu erstellen, welcher einer bestimmten Version oder Empfehlung folgt. Da allerdings die Namensräume passend angegeben sind, ist das gleichwohl eine wohldefinierte Versionsangabe. Diese geht lediglich über die eigenen Möglichkeiten von HTML5 hinaus, nicht aber über die von EPUB. Da ohnehin die XHTML-Variante von HTML5 verwendet wird, sind aber auch Namensräume verwendbar und somit ergibt sich damit ein korrektes Dokument.

Nützlich ist die Anwendung von prefix und type unter anderem auch für Gedichte und viele andere semantische Strukturen, die durch XHTML alleine nicht ausdrückbar sind und für welche es weder in EPUB noch in XHTML ein passendes Vokabular gibt, wohl aber etwa in LML:

<?xml version="1.0" encoding="UTF-8" ?> 
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ops="http://www.idpf.org/2007/ops"
      xml:lang="en"
      ops:prefix="l: http://purl.oclc.org/net/hoffmann/lml/#
                  t: http://purl.org/dc/terms/">
 <head>
  <title>Dr. Olaf Hoffmann: Ill Me</title>
  <link rel="profile" ops:type="t:conformsTo" 
        href="http://www.w3.org/TR/2013/CR-html5-20130806/"/>
  <link rel="profile" ops:type="t:conformsTo" 
        href="http://www.idpf.org/epub/30/spec/epub30-contentdocs-20111011.html"/>
 </head>
 <body ops:type="l:poetry">
  <div ops:type="l:poem">

   <div ops:type="l:header">
    <h1 ops:type="l:h">Ill Me</h1>
   </div>

   <div ops:type="l:st">
    <div ops:type="l:sl">I</div>
    <div ops:type="l:sl">Lost my rhythm</div>
    <div ops:type="l:sl">Lost my soul</div>
   </div>

   <p ops:type="l:p">
     Maybe I have to take some break ...<br />
     Else I ... will never retrieve ... what I lost
   </p>

   <div ops:type="l:prosa">
    <div ops:type="l:footer">
     <div ops:type="l:l">by
      <span ops:type="l:name">Olaf Hoffmann</span>;
      <span ops:type="l:time">2007-10-06</span>
     </div>
     <div ops:type="l:dedication">to my beloved nag</div>
    </div>
   </div>

  </div>

 </body>
</html>

Bedingte Verarbeitung

Wie bereits bei Version 2 gibt es auch bei Version 3 die Elemente switch, case und default zur bedingten Verarbeitung für Dateninseln mit Formaten, die nicht interpretiert werden müssen. switch hat als letztes Kindelement exakt ein Element default mit nicht optionalem Inhalt. Die anderen Elemente sind case-Elemente. Die Elemente gehören zum Namensraum von EPUB 'http://www.idpf.org/2007/ops'.
In der OPF-Datei ist bei dem item entsprechend bei properties in der Werte-Liste 'switch' anzugeben.

Optional kann bei allen drei Elementen ein Attribut id mit der üblichen Bedeutung notiert werden.

Zur Angabe einer Möglichkeit der bedingten Verarbeitung dient das Element case. Mit dem erforderlichen Attribut required-namespace wird der Namensraum des Formates angegeben, welches im case verwendet wird. Entsprechend ist dann der Inhalt von case im XML-Format, welches zu dem Namensraum gehört. Das in Version 2 noch verfügbare Attribut required-modules ist in Version 3 gestrichen, was zumindest auch teilweise daran liegen kann, daß HTML5 keine Module aufweist, allenfalls Erweiterungen. Auch viele andere Formate sind nicht modular aufgebaut, was sich in Zukunft aber auch wieder ändern könnte.

Besonders kritisch wird es um die bedingte Verarbeitung natürlich, wenn die Möglichkeiten für Alternativen bereits von EPUB und XHTML so eingeschränkt wurden, daß keine Alternativen mehr verfügbar sind - zwangsläufig ist es dann notwendig, entweder auf ein anderes Format auszuweichen oder aber XHTML-Konstrukte so umzubiegen und abgewandelt zu verwenden, daß der beabsichtigte Inhalt zumindest ungefähr sinngemäß beschrieben oder repräsentiert wird.

Beispiel passend zu obigem mit dem Gedicht in LML:

<div class="lml">
 <ops:switch xmlns:ops="http://www.idpf.org/2007/ops">
  <ops:case required-namespace="http://purl.oclc.org/net/hoffmann/lml/">
   <literature version="1.0" xml:lang="en"
       xmlns="http://purl.oclc.org/net/hoffmann/lml/">
    <poetry>
     <poem>

      <header>
       <h>Ill Me</h>
      </header>

      <st>
       <sl>I</sl>
       <sl>Lost my rhythm</sl>
       <sl>Lost my soul</sl>
      </st>

      <p>
        Maybe I have to take some break ...<br />
        Else I ... will never retrieve ... what I lost
      </p>

      <prosa>
       <footer>
        <l>by
         <name>Olaf Hoffmann</name>;
         <time">2007-10-06</time>
        </l>
        <dedication">to my beloved nag</dedication>
       </footer>
      </prosa>

     </poem>
    </poetry>              
   </literature>
  </ops:case>
  <ops:default>
   <div ops:prefix="l: http://purl.oclc.org/net/hoffmann/lml/#"
        ops:type="l:poetry" 
        xml:lang="en">
    <div ops:type="l:poem">

     <div ops:type="l:header">
      <h1 ops:type="l:h">Ill Me</h1>
     </div>

     <div ops:type="l:st">
      <div ops:type="l:sl">I</div>
      <div ops:type="l:sl">Lost my rhythm</div>
      <div ops:type="l:sl">Lost my soul</div>
     </div>

     <p ops:type="l:p">
       Maybe I have to take some break ...<br />
       Else I ... will never retrieve ... what I lost
     </p>

     <div ops:type="l:prosa">
      <div ops:type="l:footer">
       <div ops:type="l:l">by
        <span ops:type="l:name">Olaf Hoffmann</span>;
        <span ops:type="l:time">2007-10-06</span>
       </div>
       <div ops:type="l:dedication">to my beloved nag</div>
      </div>
     </div>

    </div>
   </div>
  </ops:default>
 </ops:switch>
</div>

Multimedia-Kontrolle

HTML5 selbst sieht keine deklarative Kontrolle von Multimedia-Elementen vor, die vom Autor gezielt eingesetzt werden können. Darstellungsprogramme haben allerdings eigene Steuerelemente für die neuen Elemente audio und video bereitzustellen, nicht jedoch etwa für object, weswegen eine von EPUB 3 bereitgestellte Erweiterung dafür sehr hilfreich wäre, von EPUB 3 leider aber gleich wieder ausgeschlossen wird. Nützlicher wäre der Einsatz für object, weil die neuen Elemente Zugänglichkeitsprobleme aufweisen, die mit dem flexibleren object vermieden werden können.

EPUB bietet im eigenen Namensraum 'http://www.idpf.org/2007/ops' zur weiteren Kontrolle das Element trigger. Das Element kann sowohl im Element head als auch irgendwo im normalen Inhalt notiert werden. Auch hier kann wieder optional das Attribut id mit der üblichen Bedeutung notiert werden. Alle weiteren Attribute sind erforderlich.

Mit dem Attribut action wird die gewünschte Aktion angegeben:

'show'
Zeigen
'hide'
Verstecken
'play'
Abspielen
'pause'
Pause
'resume'
Weiter abspielen, Pause beenden
'mute'
Stummschalten
'unmute'
Stummschalten beenden

Mit dem Attribut ref wird angegeben, auf welches Objekt sich die Aktion bezieht. Der Wert ist ein Fragmentidentifizierer des betreffenden Elementes. 'show' und 'hide' sind auf alle Elemente anwendbar, der Rest nur auf audio und video.

Zwei Attribute aus dem Namensraum 'http://www.w3.org/2001/xml-events' sind ebenfalls zu notieren, dies sind event und observer. Mit event wird ein XML-Ereignis angegeben, welche die Aktion auslöst. Mittels observer wird angegeben, bei welchem Element das Ereignis stattfinden soll, also dessen Fragmentidentifizierer. Dies ist das sogenannte Zielelement.

Version 3.0.1 stellt aus demselben Namensraum drei weitere Attribute zur optionalen Verwendung bereit. Mit defaultAction wird darüber entschieden, ob die normale Aktion nach der Ereignisbehandlung durchgeführt werden soll, etwa bei einem Verweis das Wechseln zum referenzierten Dokument(fragment). Mit dem Wert 'cancel' wird die normale Aktion blockiert, sofern diese blockierbar ist, mit der Voreinstellung 'perform' ist das nicht der Fall.
Mit phase wird darüber entschieden, wann oder in welcher Phase Ereignisse registriert werden sollen. Mit dem Wert 'capture' gilt die Einfangphase, mit der Voreinstellung 'default' passiert es bereits entweder beim Blubbern oder in der Zielphase.
Mit propagate wird festgelegt, ob ein Ereignis nach Registrierung für ein Element zu anderen, ebenfalls betroffenen Elementen weiterblubbern soll. Mit dem Wert 'stop' wird nicht weitergeblubbert, mit der Voreinstellung 'continue' wird weitergeblubbert, bis dieses Verhalten aufgrund anderer Ursachen ein Ende findet.

Hinsichtlich der verfügbaren Ereignisse verweist EPUB 3.0 auf die Empfehlung zu XML-Ereignissen [XEV], diese gibt allerdings nur vor, daß der Name des Ereignisses der üblichen XML-Namenskonvention folgen soll, legt aber nicht fest, welche Ereignisse verfügbar sind. Unverbindlich vorgeschlagen wird dort für eine Liste eine andere Empfehlung [D2E], es ist also zu vermuten, daß der Text in der Empfehlung von EPUB 3.0 so gemeint ist, daß man sich diesem Vorschlag unverbindlich anschließt.

Typische Ereignisse demgemäß für (X)HTML:

'load'
Dokument samt aller Einbettungen und Ressourcen geladen
'unload'
Element body wird entfernt, also Dokument geschlossen
'abort'
Laden des Dokumentes innerhalb von object unterbrochen
'error'
Fehler beim Laden des Dokumentes, für body und object
'select'
Auswahl von Text in input oder textarea
'change'
Element verliert den Fokus, nachdem der Eintrag geändert wurde, für input, select oder textarea
'submit'
Ein Formular wird abgesendet, für form
'reset'
Ein Formular wird zurückgesetzt, für form
'focus'
Ein Element bekommt den Fokus, für button, label, input, select oder textarea
'blur'
Ein Element verliert den Fokus, für button, label, input, select oder textarea
'resize'
Die Größe des Anzeigebereiches wird verändert
'scroll'
Der Anzeigebereich wird gerollt

Es gibt auch typische Ereignisse in Verbindung mit Zeigergeräten. Zu beachten ist dabei, daß nicht alle Geräte über Zeiger wie Mäuse verfügen müssen. Wenn etwa ein berührungsempfindlicher Monitor mit den Fingern gesteuert wird oder nur einzelne Navigationstasten verfügbar sind, so ist nicht notwendig ein permanenter Zeiger verfügbar, für welchen die Ereignisse zutreffen. Bei Darstellungen ohne Monitor entfällt die Möglichkeit ohnehin. Autoren müssen also Methoden bereitstellen, mit denen die gewünschte Aktion auch ohne Zeigergerät erfolgen kann.

'click'
Klickereignis über dem Zielelement, Mausknopf gedrückt und wieder losgelassen
'mousedown'
Mausknopf wird über dem Zielelement gedrückt
'mouseup'
Mausknopf wird über dem Zielelement losgelassen
'mouseover'
Zeiger wird bewegt, so daß der Zeiger sich über dem Zielelement befindet
'mousemove'
Zeiger wird bewegt, während er sich über dem Zielelement befindet
'mouseout'
Zeiger wird vom Zielelement wegbewegt, so daß er sich nicht mehr über dem Zielelement befindet

Typische interaktive Ereignisse:

'DOMFocusIn'
Ein fokussierbares Zielelement bekommt den Fokus
'DOMFocusOut'
Ein fokussierbares Zielelement verliert den Fokus
'DOMActivate'
Ein Zielelement wird aktiviert, unabhängig von der Methode, also besser zugänglich als ein Zeigergerät-Ereignis

Ein Video könnte dann etwa wie im folgenden Beispiel interaktiv angesteuert werden. Weil Video-Formate optional sind und das Element video hier aber gemäß HTML5verwendet werden sollte, wird die notwendige Textalternative als Abbildungsunterschrift für alle lesbar eingefügt. Zudem wird sowohl das Ereignis 'click' als auch 'DOMActivate' zu Ansteuerung verwendet, um bessere Zugänglichkeit zu gewährleisten. Da das Darstellungsprogramm für Video ohnehin eine eigene Steuerung dem Nutzer verfügbar machen muß, ist sichergestellt, daß die Funktion immer verfügbar ist.

<figure 
  xmlns:ops="http://www.idpf.org/2007/ops"
  xmlns:e="http://www.w3.org/2001/xml-events">
 <video id="Plumps"
   src="Plumpssack.ogg"
   width="600" height="480" />
 <figcaption>
   <p>
   Auf Hassans achtzehnten Geburtstag spielt dieser mit seinen Freunden
   Rainer, Emilia, Dörthe, Hannah, Asye, Ebru, Murrad, David und Bernhard 
   das bekannte Spiel der Plumpssack geht um.
   </p>
   <p>
   Die schnelle Ayse holt Hassan spielend ein.
   In der nächsten Runde verpennt Bernhard den Plumpssack total und ist
   nun dran. Es gelingt ihm jedoch in der nächsten Runde, den Plumpssack 
   Murrad anzuhängen, dem es wiederum nicht gelingt, Emilia zu überlisten
   und dann auch an Dörthe scheitert, aber schließlich schneller als Rainer ist.
   Rainer trickst David aus, der wiederum Hannah überlistet, welche den
   Plumpssack Ebru anhängt, die wiederum schneller als Hassan ist.
   </p>
   <ops:trigger e:observer="i_pause" e:event="click" action="pause" ref="Plumps"/>
   <ops:trigger e:observer="i_resume" e:event="click" action="resume" ref="Plumps"/>
   <ops:trigger e:observer="i_mute" e:event="click" action="mute" ref="Plumps"/>
   <ops:trigger e:observer="i_unmute" e:event="click" action="unmute" ref="Plumps"/>
   
   <ops:trigger e:observer="i_pause" e:event="DOMActivate" action="pause" ref="Plumps"/>
   <ops:trigger e:observer="i_resume" e:event="DOMActivate" action="resume" ref="Plumps"/>
   <ops:trigger e:observer="i_mute" e:event="DOMActivate" action="mute" ref="Plumps"/>
   <ops:trigger e:observer="i_unmute" e:event="DOMActivate" action="unmute" ref="Plumps"/>
   <ul>
     <li id="i_resume">Video abspielen<li>
     <li id="i_pause">Video abspielen pausieren<li>
     <li id="i_mute">Ton aus<li>
     <li id="i_unmute">Ton an<li>
   </ul>
 </figcaption>
</figure>

Klassen für alternative Stilvorlagen

Alternative Stilvorlagen können in XHTML ja sowohl mit XML-Stilvorlagenverarbeitungsanweisungen als auch mit dem Element link angegeben werden.
Zusätzlich ist es wohl bei einigen Darstellungsprogrammen möglich, etwa für das Lesen tagsüber und nachts die Stilvorlage des Darstellungsprogrammes zu wechseln. Es gibt insgesamt zwei Paare. Das erste, bereits genannte gilt der Beleuchtungssituation - nachts eher helle Schrift auf dunklem Grund, tags eher dunkle Schrift auf hellem Grund. Das zweite berücksichtigt das Aspektverhältnis des Anzeigebereiches, horizontal und vertikal, wobei die genannte Richtung immer größer oder gleich der nicht genannten Richtung ist.

EPUB 3 bietet nun die Möglichkeit, zumindest bei der Angabe von alternativen Stilvorlagen mittels link zu kennzeichnen, welche Autorenstilvorlage gut zu welcher Lesesituation paßt, damit diese im Bedarfsfalle automatisch ausgewählt werden kann - unbetroffen ist davon natürlich die Möglichkeit, beliebige Stilvorlagen per Name auszuwählen.

EPUB 3 legt nun für das Attribut link Werte für das Attribut class fest, die die beabsichtigte Lesesituation angeben. Zu bedenken ist dabei, daß der Wert eines Attributes class eine mit Leerzeichen separierte Liste von Werten ist, man kann also kombinieren, wobei sich Paare wie tags und nachts oder horizontal und vertikal gegenseitig ausschließen.
Die vordefinierten Werte für die jeweiligen Lesesituationen sind:

'day'
tags
'night'
nachts
'horizontal'
horizontal
'vertical'
vertikal

Das könnte dann im Kopf eines XHTML-Dokumentes zum Beispiel so aussehen:

<link rel="Stylesheet" title="Horizontal am Tage" class="day horizontal" 
     href="AmTageH.css"/>
<link rel="Alternate Stylesheet" title="Horizontal in der Nacht" class="night horizontal" 
     href="NachtsH.css"/>
<link rel="Alternate Stylesheet" title="Vertikal am Tage" class="day vertical" 
     href="AmTageV.css"/>
<link rel="Alternate Stylesheet" title="Vertikal in der Nacht" class="night vertical" 
     href="NachtsV.css"/>

Beziehungsweise, weil es ohnehin geschickter ist, die Frage des Aspektverhältnisses im Bedarfsfalle genauer mit einer Medienanfrage zu behandeln, reicht an dieser Stelle eigentlich die Berücksichtigung der Tageszeit:

<link rel="Stylesheet" title="Am Tage" class="day" 
     href="AmTage.css"/>
<link rel="Alternate Stylesheet" title="Nachts" class="night" 
     href="Nachts.css"/>

MathML-Dateninseln

MathML-Dateninseln in XHTML sind erlaubt, wobei allerdings der Inhalt des Elementes mathml in EPUB 3 auf Präsentations-MathML einschränkt wird, was zumindest insofern erstaunlich ist, als ansonsten in (X)HTML seit HTML4 gezielt auf Präsentationsattribute verzichtet wird, hier ergibt sich wohl ein Rückfall in alte Zeiten, wo Präsentation und Inhalt auch noch gemischt wurden, ein Anzeichen dafür, wie unausgegoren dieser Teil von EPUB 3 ist.
Zugeben muß man auf jeden Fall, daß MathML so oder so nicht gerade komfortabel zu notieren ist und die Präsentations-Variante dabei wenigstens für Autoren etwas einfacher ist als die Inhalts-Variante, die besser durch Programme zu verarbeiten ist.

Es gibt allerdings eine Ausnahme. Im Namensraum von MathML kann im Element annotation-xml, welches wiederum ein Kindelement von semantics sein muß. Das zu annotation-xml gehörige Attribut encoding ist dann ferner auf einen der gleichwertigen Werte 'MathML-Content' oder 'application/mathml-content+xml' zu setzen. Zusätzlich ist das Attribut name auf den Wert 'contentequiv' zu setzen. Der Inhalt ist also per Definition äquivalent zum entsprechend ebenfalls zu notierenden Präsentations-MathML.

Als veraltet gekennzeichnete Elemente von MathML dürfen nicht verwendet werden. Auch extern in den Dokumenttypdefinitionen definierte Entitäten dürfen nicht verwendet werden, sofern diese nicht per lokaler Definition selbst definiert werden.

XHTML wiederum kann auch in MathML verwendet werden, wobei dies nur zulässig ist im Element annotation-xml, welches wiederum ein Kindelement von semantics sein muß. Das zu annotation-xml gehörige Attribut encoding ist dann ferner auf den Wert 'application/xhtml+xml' zu setzen. Zusätzlich ist das Attribut name auf den Wert 'alternate-representation' zu setzen.
Derartige XHTML-Dateninseln dürfen selbst keine weiteren MathML-Dateninseln mehr enthalten.
Der XHTML-Inhalt ist dabei so auszuwählen, daß wenn dieser die umgebende MathML-Dateninsel ersetzt, sich immer noch ein korrektes XHTML-Dokument ergibt, die Struktur also immer noch paßt.

Darstellungsprogramme sollen das MathML interpretieren. Allerdings sollen Autoren trotzdem alternativen Inhalt bereitstellen, um Zugänglichkeit auch bei jenen Programmen zu gewährleisten, die sich nicht daran halten. Dazu dient primär das Attribut alttext des Elementes mathml, falls kurze Textalternativen ausreichen. Ansonsten sollte XHTML als Alternative verwendet werden.

Fixiertes Layout

Dies ist eine Erweiterung von Version 3.0.1, die für Inhaltsdokumente in beiden Formaten XHTML und SVG zutrifft. Insbesondere für XHTML-Dokumente können damit ähnliche Anzeigeeigenschaften erreicht werden wie für SVG-Dokumente mit viewBox und Breite und Höhe nicht angegeben oder nicht mit Prozentwerten festgelegt.
Zunächst müssen all diese Dokumente in der OPF-Datei als 'pre-paginated' festgelegt sein, siehe oben im entsprechenden Abschnitt zu Metainformationen.

Bei XHTML-Dokumenten ist sodann in diesen je ein Element meta zu notieren, welches den Anzeigebereich festlegt. Die genaue Spezifikation ist proprietär und stammt offenbar von Apple, ist ferner nicht allgemein zugänglich. Daher ist hier das meiste undefiniert, offenbar ist aber sinngemäß zu wiederholen, was schon in der OPF-Datei anzugeben war, warum hier noch einmal in proprietärer Form, bleibt ungeklärt. Folgendes ist ein Beispiel:

<meta name="viewport" content="width=1200, height=600"/>

Mutmaßlich sind die Zahlenangaben CSS-Pixel mit den oben bereits im Kapitel über die entsprechenden Metainformation in der OPF-Datei erläuterten Implikationen. Was über den Bereich übersteht, wird abgeschnitten und nicht angezeigt, ist für die Leser also gegebenenfalls unzugänglich, weshalb man von der Verwendung dieser Funktion nur eindringlich abraten kann, weil ein Autor den für die Darstellung des Inhalts benötigten Platz gar nicht sinnvoll abschätzen kann, jedenfalls wenn dieser zum guten Teil aus Text besteht, bei welchem der Leser die Schriftgröße für sich optimal eingestellt hat.

Mit Stilvorlagen im Format CSS kann man natürlich bereits für Version 2 Höhe und Breite der Anzeige festlegen und zudem explizit angeben, ob gegebenenfalls dabei abgeschnittener Inhalt zugänglich gemacht werden soll. Von daher ist auch für Version 3 eher diese Variante zu empfehlen, welche zudem deutlich mehr Möglichkeiten bietet, insbesondere auch bei der Wahl geeigneterer Einheiten, etwa in Prozent des Anzeigebereiches oder in Einheiten wie em oder ex. Dies bietet für den Leser auch einfach die Möglichkeit, durch Deaktivierung der Interpretation der Stilvorlage wieder eine Präsentation zu bekommen, welche sich automatisch an den verfügbaren Platz anpaßt. Auch von daher erscheint diese Erweiterung des 'fixiertes Layouts' eher als unsinnig.

Die Notation von Höhe und Breite in Pixeln als Inhalt im XHTML-Dokument ist natürlich auch problematisch, wenn mehrere alternative Stilvorlagen verfügbar sind, welche unterschiedlich viel Platz benötigen. Das fundamentale Prinzip des Schichtenmodells zur Trennung von Inhalt und Präsentation/Dekoration wird mit dieser proprietären Erweiterung schlichtweg ignoriert, mit der Konsequenz, daß aus der Anwendung praktisch notwendig für diese oder jene Nutzergruppe Unfug und Drama provoziert wird.

Bei SVG-Dokumenten ist für diese Art der Darstellung immer das Attribut viewBox zu verwenden. Dies ist ohnehin immer sinnvoll. Irreführend ist allerdings die Behauptung in EPUB, diese viewBox hätte generell etwas mit CSS-Pixeln zu tun. Dies ist in mancherlei Hinsicht komplett falsch. Zum einen verwendet SVG 1.1 noch CSS 2.0, welches nicht den irreführenden Zusammenhang zwischen Pixeln und absoluten Längenangaben beeinhaltet. Zudem sind die Werte in der Liste von viewBox Angaben in lokalen Einheiten. Eine präsentierte Größe ergibt sich daraus erst durch weitere Transformationen, die von Höhe und Breite des SVG-Dokumentes abhängen, davon, ob das Aspektverhältnis erhalten bleiben soll. Leider wurde meine diesbezügliche Nachfrage bislang ignoriert, die ich bereits gestellt hatte, bevor Version 3.0.1 als fertig veröffentlicht wurde. Von daher kann andererseits auch als bekannt vorausgesetzt werden, daß da irreführender Unfug spezifiziert wurde. Im Folgenden drei Beispiele, wo der Unfug offensichtlich wird:

<svg version="1.1" xmlns="http://www.w3.org/2000/svg"
 width="20em" height="20em" viewBox="-100 -50 200 400" preserveAspectRatio="none" >
 <!-- etc -->
 </svg>

Hier ist es offenbar gerade erwünscht, daß der Anzeigebereich auf jeden Fall quadratisch ist, was in der viewBox ist, soll so skaliert werden, daß das Quadrat mit einer Seitenlänge von 20em komplett damit gefüllt wird.

<svg version="1.1" xmlns="http://www.w3.org/2000/svg"
 viewBox="-100 -100 200 200" preserveAspectRatio="none" >
 <!-- etc -->
 </svg>

Hier ist es offenbar das Ziel, daß der Bereich der viewBox immer so skaliert wird, daß der verfügbare Anzeigebereich damit immer komplett ausgefüllt wird.

<svg version="1.1" xmlns="http://www.w3.org/2000/svg"
 preserveAspectRatio="xMidYMid slice" viewBox="0 0 40 40">
 <!-- etc irgendein Muster -->
 </svg>

Dies dient vor allem dazu, etwa bei einem Penrose-Muster keine leeren Ecken zu bekommen, sondern immer so zu skalieren, daß der komplette Anzeigebereich mit etwas gefüllt wird, was in der viewBox ist, was außerhalb ist, sollte nie sichtbar werden.

Attribute zur Konversion von Text zu Sprache

Autoren können Vorleseprogrammen helfen, um eine bessere Aussprache zu erzielen. Dazu werden Attribute von SSML verwendet. Die Attribute sind mit einem Präfix für den Namensraum von SSML zu notieren: 'http://www.w3.org/2001/10/synthesis'.

Mit dem Attribut ph wird die Aussprache des Elementinhaltes angegeben. Der Wert ist ein phonetischer Ausdruck.

Das für den phonetischer Ausdruck verwendete Alphabet wird mit dem Attribut alphabet angegeben. Der Wert ist der Name des Alphabets. Da der Wert vererbt wird, gilt er für alle Nachfahren ohne eigene Angabe.

Nicht zu benutzende Elemente und Elemente mit Zugänglichkeitsproblemen

HTML5 enthält einige problematische Elemente oder solche, die schlichtweg überflüssig sind.

Da etwa Ruby-Notation nunmehr interpretiert werden muß, erweist sich das Element rp als überflüssig und braucht gemäß EPUB 3 nicht verwendet zu werden. Indes erweist sich beim aktuellen Implementierungstatus bei den üblichen Darstellungsprogrammen dies als frommer Gedanke, weswegen man nicht wirklich davon ausgehen kann, daß Ruby-Notation durchgehend interpretiert wird.

Das in HTML5 neu eingeführte Element embed bietet keine Möglichkeit, zugängliche Alternativen für nicht interpretierte Formate anzugeben. Das Element ist komplett überflüssig. In EPUB 3 ist stattdessen im Bedarfsfalle das Element object zu verwenden.

Neben diesen beiden Ausschlüssen, die bereits in EPUB 3 erwähnt sind, gibt es einige weitere Problemfälle. Etwa führt HTML5 selbst an, daß wenn möglich statt dem Element canvas besser geeignete Techniken verwendet werden sollen. Das ist in der Praxis eigentlich immer möglich, weil canvas eine Malfläche darstellt, die nur genutzt werden kann, wenn Skriptinterpretation aktiviert ist. Ansonsten stellt der Inhalt die Alternative dar.

Das Element dialog wurde ursprünglich in den ersten Arbeitsentwürfen für Dialoge definiert, später entsorgt und noch später in ein problematisches Gebilde umgewidmet, welches ein großes Potential hat, Zugänglichkeitsprobleme zu bereiten. Aufgrund eines Attributes wird der Inhalt entweder gar nicht dargestellt oder aber er verdeckt den Inhalt, welcher auf das Element folgt (jedenfalls in einer Implementierung, die in einigen Versionen von WebKit verfügbar ist). Das Element sollte auf gar keinen Fall verwendet werden.

Auch die neu definierten Elemente audio und video haben Zugänglichkeitsprobleme, auch weil ihr Inhaltsmodell gegenüber dem vom flexibleren object ungeschickt vereinfacht wurde. Zwar können alternative Formate angegeben werden, es ist aber etwa nicht möglich, eine reine (X)HTML-Alternative anzugeben für den Fall, daß gar keines der Formate interpretiert werden kann. Sofern die Elemente also verwendet werden, tragen sie per Definition also gar nicht zum Inhalt bei, sind also nur dekorativ oder der Autor muß eine zugängliche Alternative dazu als zusätzlichen Inhalt anbieten, also nicht nur alternativ.
Autoren von EPUB-Büchern müssen allerdings immer Alternativen zu Dokumenten in Formaten angeben, welche nicht interpretiert werden müssen, folglich also etwa zu allen Video-Dateien und wegen genannter Probleme auch zu allen Audio-Dateien. Letztlich sind diese Alternativen immer Inhaltsdokumente oder Fragmente von Inhaltsdokumenten, also vom Format XHTML oder SVG. Die Elemente audio und video eignen sich selbst aber explizit nicht für Dokumente in diesen Formaten, woraus indirekt folgt, daß die zugänglichen Alternativen anderweitig einzubetten oder zu referenzieren sind.

Ferner stehen einige Elemente und Konstrukte der Arbeitsentwürfe von HTML5 auf einer Abschußliste, wurden vor der Veröffentlichung der Empfehlung also bereits entsorgt. Andere Elemente wie main sind erst eingefügt worden, nachdem EPUB 3 zur Empfehlung wurde, werden also in frühen Versionen von Darstellungsprogrammen von EPUB 3 noch nicht interpretiert werden.
Eine voreingestellte Präsentation per CSS festzulegen, ist nicht ausreichend, weil Leser die Interpretation von CSS deaktivieren können. Allerdings haben viele neue Elemente von HTML5 mit semantischer Bedeutung keine sinnvolle voreingestellte Präsentation, auch weil der Vorschlag in HTML5 selten davon abweicht, diese wie die Elemente div oder span zu präsentieren, ihre Bedeutung ist also meist anhand der voreingestellten visuellen Präsentation der Darstellungsprogramme gar nicht erkennbar. Dies ist an sich bereits ein weiterer gravierender Mangel von HTML5, aber auch ein Versäumnis der Anbieter von Darstellungsprogrammen, die dies widerspruchslos übernommen haben.

Stilvorlagen

Für Stilvorlagen wird CSS verwendet. Während Version 2 sich auf Teile von CSS 2.0 mit wenigen Erweiterungen beschränkt, bietet sich für Version 3 ein reichhaltiger Flickenteppich, der zu einem großen Teil aus CSS 2.1 besteht, zu einem geringen Teil aus CSS 2.0. Hinzu kommen Medienanfragen [MA], das Modul für Namensräume [NS] und einige Module von CSS 3, von denen es die meisten bis heute nicht zum Status einer Empfehlung gebracht haben. Wie schon mit den Arbeitsentwürfen zu HTML5 setzt EPUB 3 auch hier auf Unfertiges und Experimentelles.

Aus CSS 2.0 stammen lediglich einige Werte für die Eigenschaft list-style-type: 'cjk-ideographic', 'hebrew', 'hiragana', 'hiragana-iroha', 'katakana', 'katakana-iroha'. Diese wurden lediglich in CSS 2.1 gestrichen, was man aber offenbar für EPUB 3 nicht gelten lassen mag.

Von CSS 2.1 explizit ausgeschlossen wird von EPUB 3 der Wert 'fixed' der Eigenschaft position. Ebenfalls ausgeschlossen werden die Eigenschaften direction und unicode-bidi, die für das Überschreiben der normalen Schreibrichtung vorgesehen sind. Stattdessen sollen in Dokumenten für EPUB 3 im Bedarfsfalle die entsprechenden Möglichkeiten von XHTML genutzt werden.

Die auralen Stilvorlagen von CSS 2.0 werden auszugsweise mit eigenen Präfixen teilweise weitergeführt, wobei man sich auf einen Arbeitsentwurf zu einem Modul von CSS 3 bezieht [CSSS], welches wiederum auf den ursprünglichen auralen Stilvorlagen von CSS 2.0 beruht. Verwendbar sind demgemäß: -epub-cue, -epub-pause, -epub-rest, -epub-speak, -epub-speak-as, -epub-voice-family.

Während in Version 2 noch die Regel @font-face von der Empfehlung CSS 2.0 verwendet wird, bezieht sich Version 3 stattdessen auf einen entsprechenden Arbeitsentwurf für ein Modul von CSS 3. Notwendig zu interpretierende Deskriptoren der Regel @font-face sind: font-family, font-style, font-weight, src, unicode-range.
Die Auswahl ist also etwas anders als bei Version 2.

Eine weitere Kollektion von Eigenschaften mit Präfix bezieht sich auf einen Arbeitsentwurf des Textmoduls von CSS 3 [CSST]. Es gibt folgende Eigenschaften: -epub-hyphens (ohne den Wert 'all'), -epub-line-break, -epub-text-align-last, -epub-text-emphasis, -epub-text-emphasis-color, -epub-text-emphasis-style, -epub-word-break.

Ebenfalls verfügbar gemacht wird das Modul für mehrspaltige Darstellung [CSSM]. Ausgenommen ist dabei die Eigenschaft column-span.

Neu eingeführt wird für EPUB 3 die Eigenschaft -epub-ruby-position. Die Eigenschaft wird vererbt und gilt für visuelle Medien. Es dient dazu, die Anordnung von Ruby-Notation festzulegen. Folge Werte sind vorgesehen:

'over'
Über dem Haupttext, der Initialwert
'under'
Unter dem Haupttext
'inter-character'
Rechts vom Haupttext
'inherit'
geerbt

Die Werte 'oeb-page-head' und 'oeb-page-foot' für die Eigenschaft display sind wie bereits in Version 2 definiert verfügbar. Ab Version 3.0.1 sind sie allerdings als veraltet gekennzeichnet und sollten nicht mehr verwendet werden.

Version 3.0.1 erlaubt nun auch Selektoren gemäß dem CSS-3-Modul.
Diese Version erlaubt auch Teile eines bestimmten Arbeitsentwurfes des CSS-3-Modules für Textdekoration, allerdings mit eigenem Präfix. Das Modul selbst befindet sich allerdings erst im Stadium eines Arbeitsentwurfes, kann sich also jederzeit ändern - warum diese Übereilung und die Einführung eines eigenen Präfixes, welches ohnehin nicht dauerhaft oder überhaupt implementiert bleiben wird.
Ähnlich verhält es sich mit einem bestimmten Arbeitsentwurf zum CSS-3-Modul für die Schreibrichtung, auch hier wird eine mit Präfix versehene Variation des offiziellen Arbeitsentwurfes als brauchbar suggeriert.

Korrekte Betonung für Sprachausgabe

Zusätzlich zu den bereits diskutierten Möglichkeiten, die korrekte Betonung von Elementinhalten anzugeben, kann auch je ein komplettes Lexikon mit solchen Angaben für die jeweils verwendeten Sprachen angegeben werden. Dazu dient das Format PLS [PLS].

Die Einbindung in ein XHTML-Dokument erfolgt mit dem Element link im Dokumentkopf. Bei dem Element sind dann Attribute mit bestimmten Werten zu verwenden:
rel='pronunciation' und
type='application/pls+xml'.
Das Attribut hreflang soll auf einen Wert gesetzt werden, welcher für die Sprache steht, für welche das Lexikon relevant ist, also etwa 'de' für deutsch allgemein oder auch 'de-DE' für hochdeutsch, 'de-AT' für österreichische Aussprache, 'de-CH' für schweizer Aussprache, 'en-US' für englisch im amerikanischen Dialekt etc.
Mit dem Attribut href wird natürlich das Lexikon referenziert.
Somit ergeben sich folgende Beispiele:

<link rel="pronunciation" type="application/pls+xml" hreflang="de-AT" href="betonungslexikon/de-at.pls"/>
<link rel="pronunciation" type="application/pls+xml" hreflang="de-CH" href="betonungslexikon/de-ch.pls"/>

Entsprechend ist dann im Inhalt natürlich per xml:lang zu notieren, welche Sprache für das aktuelle Element zutrifft, damit der Sprachsynthetisierer dafür auch das richtige Lexikon verwenden kann.

Medienüberlagerung

Zusätzlich zur primären Textvariante des Buches kann auch eine akustische Präsentation bereitgestellt werden. Neben der zuvor erläuterten synthetischen Sprachausgabe der Textvariante können auch Audio-Dateien mit menschlichen Sprechern mit der Textvariante korreliert werden. Die dazu verwendeten speziellen Dateien im Format SMIL werden ebenfalls in EPUB 3 beschrieben, wofür SMIL auf einen winzigen Teilbereich dieses Formates eingeschränkt wird. Ferner wird anders als bei SMIL 3 für EPUB 3 ein sehr spezielle Dokumentstruktur festgelegt.

Die Interpretation durch Darstellungsprogramme ist allerdings optional. Wenn sie verfügbar ist, muß sie für XHTML-Dokumente verfügbar sein und kann ebenfalls für SVG-Dokumente verfügbar sein.

Die verwendeten Elemente gehören zum Namensraum von SMIL, also 'http://www.w3.org/ns/SMIL'. Das Wurzelelement heißt smil und hat das erforderliche Attribut version='3.0'.

smil kann ein Attribut id mit der üblichen Funktion eines Fragmentidentifizierers haben. Einmal mehr zeigt sich hier, daß EPUB 3 mit diesem Attribut wirklich auf dem Kriegsfuß steht. Während SMIL 3.0 dieses als veraltet kennzeichnet und dringend rät, es bei neu angelegten Dokumenten nicht mehr zu verwenden, sondern stattdessen das generische xml:id, besteht EPUB 3 auf die Verwendung von id.

smil bekommt für EPUB 3 auch noch eine Erweiterung, welche aus dem bereits beschriebenen Attribut prefix besteht, welches aber nicht zu SMIL gehört, sondern zum Namensraum von OPS, also 'http://www.idpf.org/2007/ops'.

Der Inhalt von smil besteht aus einem optionalen Element head und einem erforderlichen Element body.

head kann lediglich ein Element metadata enthalten. metadata kann Metainformationen in Form von Elementen aus anderen Namensräumen enthalten. Ähnlich wie bei SVG ist der Autor hier frei in der Auswahl der Formate für die Metainformationen. Insbesondere können natürlich Dublin Core und das Element meta aus dem Namensraum 'http://www.idpf.org/2007/opf' verwendet werden, also was auch im OPF-Dokument für Metainformationen verwendet wird.

body kann optionale Attribute haben, neben dem üblichen id gibt es noch zwei weitere, die eine Erweiterung aus dem Namensraum von OPS, also 'http://www.idpf.org/2007/ops' darstellen. Dies ist zum einen das bereits erläuterte Attribut type für die semantische Bedeutung des Elementes. Zum anderen gibt es das Attribut textref , mit welchem das Inhaltsdokument referenziert werden kann, auf welches sich die Medienüberlagerung bezieht. Der Wert ist also eine relative IRI zu diesem Dokument. Optional ist dies auch insbesondere deshalb, weil ein solcher Zusammenhang im Grunde bereits im manifest der OPF-Datei anzugeben ist.

Der Inhalt von body besteht aus einer beliebigen positiven Anzahl von Elementen par und seq in beliebiger Reihenfolge.

seq ist ein Container für Inhalte, die nacheinander (sequentiell) präsentiert werden, par für solche, die gleichzeitig (parallel) präsentiert werden. Beide können wiederum optional ein Attribut id und auch wieder ein type aus dem OPF-Namensraum haben.

Erforderlich für seq ist das bereits beschriebene Attribut textref , ebenfalls aus dem OPF-Namensraum. Referenziert wird damit das Fragment des Inhaltsdokumentes, auf welches sich die aktuelle Mediensequenz bezieht.

Der Inhalt von seq kann aus einer beliebigen positiven Anzahl von Elementen seq und par in beliebiger Reihenfolge bestehen. Die Korrelation zum Inhaltsdokument kann man sich so vorstellen, daß die verschachtelten Elemente seq die Dokumentstruktur des Inhaltsdokumentes abbilden können. Der eigentliche, letztlich korrespondierende akustische Inhalt steht hingegen in den Elementen par. Entsprechend sollte auch mittels des Attributes type die semantische Funktion oder Bedeutung der jeweiligen Struktur angegeben werden. Da die korrespondierenden Elemente als XHTML notiert sind, werden allerdings in den Vokabluarien von EPUB 3 oder XHTML oft die passenden Einträge fehlen, weil diese Vokabularien meist auslassen, was ohnehin bereits in XHTML vorhanden ist. Daher kann es also notwendig sein, ein anderes Vokabularium zu verwenden, welches die Struktur von literarischen Dokumenten besser abbildet, etwa das bereits genannte LML [LML].

Der Inhalt eines Elementes par besteht auf einem erforderlichen Element text und einem Element audio. audio ist nur optional, wenn sich par im Inhaltsdokument auf ein Element mit akustischer Ausgabe bezieht oder auf eine Passage, die für eine synthetische Sprachausgabe gedacht ist.

Das inhaltsleere Element text dient direkt dazu, das Fragment eines Inhaltsdokumentes zu referenzieren, auf welche sich die aktuelle Mediensequenz bezieht. Das Attribut id mit der üblichen Bedeutung kann angegeben werden. Mit dem erforderlichen Attribut src wird die relative IRI samt Fragmentidentifizierer des Elementes angegeben, auf welches sich die aktuelle Mediensequenz bezieht.

Das inhaltsleere Element audio ist nicht zu verwechseln mit dem gleichnamigen Element aus dem Namensraum von XHTML, welches später eingeführt wurde und eine ganz andere Struktur hat. Dies SMIL-Element bettet jedenfalls (zumeist) ebenfalls eine Audio-Datei ein, anders als HTML5 legt sich SMIL dabei allerdings nicht wirklich fest, EPUB 3 hingegen schon.

Bei text kann ein Attribut id mit der üblichen Bedeutung angegeben werden. Auch hier ist das Attribut src erforderlich und muß eine Audio-Datei referenzieren. Das Format der Datei muß ein Kernmedientyp sein. Für Audio-Dateien sind dies MP3 (audio/mpeg) oder AAC-LC mit MP4-Container (audio/mp4). Da die Implementierung beider Formate eine Lizenz erfordert, kann dies bestimmte Darstellungsprogramme für Medienüberlagerung von vorne herein ausschließen. Einmal mehr zeigt sich EPUB 3 damit als reichlich unausgegoren, weil kein lizenzfreies Format erlaubt oder erforderlich interpretierbar ist und somit künstlich Barrieren aufgebaut werden, die diesen Teil von EPUB 3 für bestimmte Nutzergruppen unbrauchbar machen.

Weitere Attribute von audio sind optional und dies sind clipBegin und clipEnd. Beides gibt Zeitwerte gemäß Syntax von SMIL an, wobei clipEnd nicht vor clipBegin liegen darf, sonst ist die Kombination ungültig. Beides gibt Zeiten im Verlauf des Medium an, wobei 0 der Anfang der Datei ist. EPUB 3 schränkt die Möglichkeiten hier auf einfache Zeitwerte ein.

Die einfachste Möglichkeit einer Zeitangabe besteht aus einer Zahl, also etwa '37.135'. Optional kann eine Einheit angehängt werden, wenn nicht, werden Sekunden angenommen. 'h' steht für Stunden, 'min' für Minuten, 's' für Sekunden, 'ms' für Millisekunden.

Eine weitere Möglichkeit besteht darin, eine Angabe in Minuten und Sekunden zu machen, also zwei Zahlen getrennt von einem Doppelpunkt etwa so: '13:37.135'. Der Teil vor dem Doppelpunkt steht für die Minuten, der Teil dahinter für Sekunden.

Vorne kann auch noch ein Segment für Stunden angehängt werden, also etwa: '5:13:37.135'. Vor dem ersten Doppelpunkt stehen also die Stunden, der Rest wie bereits erklärt.

Eine Audio-Datei stellt typisch einen Satz, Absatz, Abschnitt oder auch ein Kapitel eines Buches dar. Die einzelnen Audio-Dateien in den Sequenzen seq repräsentieren so also letztlich das gesamte Buch beziehungsweise das gesamten Inhaltsdokument, welches mit der SMIL-Datei korreliert ist. Folgendes zeigt den Aufbau einer SMIL-Datei für ein Kapitel mit ein paar Abschnitten:

<?xml version="1.0" encoding="UTF-8" ?>
<smil xmlns="http://www.w3.org/ns/SMIL"
      xmlns:ops="http://www.idpf.org/2007/ops"
      version="3.0">
 <body>
 <seq ops:textref="k1.xhtml" ops:type="chapter">
  <!-- Kapitelüberschrift -->
  <par>
    <text src="k1.xhtml#ueb"/>
    <audio src="audio/k1.mp3" clipEnd="5.4" />
  </par>
  <!-- Abschnitte oder Absätze des Kapitels -->
  <par>                        
    <text src="k1.xhtml#ab1"/>
    <audio src="audio/k1.mp3" clipBegin="5.4" clipEnd="113.3"/>
  </par>
  <par>                        
    <text src="k1.xhtml#ab2"/>
    <audio src="audio/k1.mp3" clipBegin="113.3" clipEnd="4:03.5"/>
  </par>
  <par>                        
    <text src="k1.xhtml#ab3"/>
    <audio src="audio/k1.mp3" clipBegin="4:03.5" clipEnd="6:25.1"/>
  </par>
  <par>                        
    <text src="k1.xhtml#ab4"/>
    <audio src="audio/k1.mp3" clipBegin="6:25.1" clipEnd="8:45.7"/>
  </par>
  <par>                        
    <text src="k1.xhtml#ab5"/>
    <audio src="audio/k1.mp3" clipBegin="8:45.7"/>
  </par>
 </seq>
 </body>
</smil>

Es kann per Stilvorlage festgelegt werden, wie der gerade vorgelesene Teil dargestellt werden soll. Dazu wird im OPF-Dokument angegeben, unter welchem Klassennamen die Eigenschaften für diesen Zweck notiert sind. Der Klassenname kann frei gewählt werden, zum Beispiel 'vorlesen'. Die zugehörige Metainformation im OPF-Dokument sieht dann wie folgt aus und bezieht sich immer auf das gesamte Buch:

<meta property="media:active-class" >vorlesen</meta>

Um dies etwa rot zu umranden, könnte in der Stilvorlage angegeben werden:

.vorlesen {outline: thin solid red}

Neu ist in Version 3.0.1 die Möglichkeit, mittels eine Dekoration anzubieten, wenn ein Medium abgespielt wird, also etwa so:

<meta property="media:playback-active-class" >video-spielt</meta>

Um dies etwa rot zu umranden, könnte in der Stilvorlage angegeben werden:

.video-spielt {outline: thin solid red}

Eine weitere erforderliche Metainformation zu einer Medienüberlagerungsdatei ist die Zeit, die die Audio-Datei dauert. Sei etwa die Dauer 3 Minuten und 47 Sekunden, so sieht diese Metainformation zum Beispiel so aus:

<meta property="media:duration" refines="#k1.smil">3:47</meta>

Bei Bedarf können auch Personen genannt werden, welche den Text sprechen, pro Person dann ein Element:

<meta property="media:narrator" refines="#k1.smil">Eva Luation</meta>
<meta property="media:narrator" refines="#k1.smil">Udo Pisch</meta>

Es ist allerdings nicht festgelegt, wie bei mehreren Erzählern der jeweiligen Stimme ein Namen zugeordnet.

Ist bei diesen Metainformationen beim Element meta kein Attribut refines notiert, um anzugeben, auf welche Audio-Datei, welches item des manifest sich die Metainformation bezieht, so bezieht sie sich auf die gesamte Audio-Präsentation des Buches. Irrtümlich und fehlerhaft wird in der Empfehlung statt refines ein Attribut about erwähnt, welches aber für meta gar nicht definiert ist.

Referenzieren von Buch-Fragmenten

Um Fragmente von Büchern von außerhalb des Buches referenzieren zu können, führt EPUB 3 dafür einen Mechanismus ein, die sogenannten kanonischen Fragmentidentifizierer. Auf den ersten Blick sieht solch ein Fragmentidentifizierer recht abstrakt, allgemein und kompliziert aus, bei näherer Betrachtung stellt sich allerdings heraus, daß er recht spezifisch für Bücher im Format EPUB ist und allenfalls als allgemein hinsichtlich anderer Versionen dieses Formates angesehen werden kann. Relative Verweise innerhalb eines Buches können unverändert einfach und unproblematisch bleiben, können aber auch diesen allgemeinen Mechanismus verwenden. Das ist insbesondere nützlich, wenn auf Fragmente zu verweisen ist, welche keinen Fragmentidentifizierer notiert haben.

Bei Verweisen von außerhalb des Buches besteht zudem das Problem, daß man das jeweilige Dokument im Buch eindeutig identifizieren muß und darin das gewünschte Fragment. Die kanonischen Fragmentidentifizierer verwenden dazu einen Zählalgorithmus, um das passende Dokument zu identifizieren, wobei vom Verzeichnis aller Elemente in der OPF-Datei ausgegangen wird. Das Verfahren ähnelt formal der Referenzierung von Passagen in gedruckten Büchern, bei dem man etwa Angaben zur Seite, zum Absatz oder der Zeile macht. Es gibt ja auch gedruckte Werke mit festen Zeilen, wo gleich die Zeilen durchnumeriert sind, um solche Referenzierungen zu erleichtern. Bei dem von EPUB definierten Verfahren läßt sich eindeutig angeben, welches Element in welchem Dokument eines Buches Ziel der Referenzierung ist. Darüber hinaus läßt sich sogar auf den Buchstaben genau angeben, welches Zeichen referenziert wird.

Das eignet sich etwa auch gut für das Setzen von Lesezeichen, insbesondere wenn das Darstellungsprogramm selbst einen Mechanismus verfügbar macht, um solche Lesezeichen entsprechend zu setzen.

Wie für IRIs vorgesehen, folgt bei einer Referenz auf ein Fragment der Fragmentidentifizierer nach einem Zeichen '#', davor kann dann eine absolute oder relative IRI stehen. Kanonischen Fragmentidentifizierer beginnen mit der Buchstabenfolge 'epubcfi(' und enden mit ')'. Innerhalb der Klammer steht dann ein komplizierterer Ausdruck, welcher das Zielfragment identifiziert.

Syntax

Da die Syntax des Klammerausdrucks recht komplex ist und die Empfehlung zu EPUB auch nicht wesentlich mehr enthält, wird im Folgenden erst einmal die Syntax in EBNF-Notation wiedergegeben:

Fragment
"epubcfi(" , ( Pfad | Bereich ) , ")"
Pfad
Ausdr , LokalerPfad
Bereich
Pfad , "," , LokalerPfad , "," , LokalerPfad
LokalerPfad
{ Ausdr | "!" } , [ TermAus ]
Ausdr
"/" , NZahl , [ "[" , Bemerkung , "]" ]
TermAus
Terminus , [ "[" , Bemerkung , "]" ]
Terminus
( ":" , NZahl ) | ( "@" , NNZahl , ":" , NNZahl ) | ( "~" , NNZahl ) | ( "~" , NNZahl , "@" , NNZahl , ":" , NNZahl )
NNZahl
( NNZiffer , { Ziffer } , [ "." , { Ziffer } , NNZiffer ] ) | ( "0" , "." , { Ziffer } , NNZiffer )
NZahl
"0" | ( NNZiffer , { Ziffer } )
Bemerkung
[ CSW ] , { Par }
Par
";" , WertOhneLeerzeichen , "=" , CSW
CSW
Wert , { "," , Wert }
Wert
UMZeichenkette
WertOhneLeerzeichen
Wert - ( [ Wert ] , " " , [ Wert ] )
SpZeichen
"^" | EckigeKlammern | Klammern | "," | ";" | "="
MSZeichen
"^" , "^" | ( "^" , EckigeKlammern ) | ( "^" , Klammern ) | ( "^" , "," ) | ( "^" , ";" ) | ( "^" , "=" )
MZeichen
( Zeichen - SpZeichen ) | MSZeichen
UMZeichenkette
MZeichen , { MZeichen }
Ziffer
"0" | NNZiffer
NNZiffer
"1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
EckigeKlammern
"[" | "]"
Klammern
"(" | ")"
Zeichen
? Unicode-Zeichen ?

Die Unicode-Zeichen sind jene, die auch in XML 1.0 vorgesehen sind, ausgeschlossen sind demnach: #x9, #xA, #xD, [#x20-#xD7FF], [#xE000-#xFFFD], [#x10000-#x10FFFF].

Zu vermeiden sind ferner: [#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDEF], [#x1FFFE-#x1FFFF], [#x2FFFE-#x2FFFF], [#x3FFFE-#x3FFFF], [#x4FFFE-#x4FFFF], [#x5FFFE-#x5FFFF], [#x6FFFE-#x6FFFF], [#x7FFFE-#x7FFFF], [#x8FFFE-#x8FFFF], [#x9FFFE-#x9FFFF], [#xAFFFE-#xAFFFF], [#xBFFFE-#xBFFFF], [#xCFFFE-#xCFFFF], [#xDFFFE-#xDFFFF], [#xEFFFE-#xEFFFF], [#xFFFFE-#xFFFFF], [#x10FFFE-#x10FFFF].

Stelle im Buch referenzieren

Um ein bestimmtes Element eines Dokumentes durch eine Zahl zu identifizieren, werden die Kindelemente mit geraden Zahlen von vorne nach hinten durchnumeriert. Gibt es vor einem Kindelement Inhalt in Textform, der nicht in einem Kindelement steht, so bekommt dieser Inhalt die nächstkleinere ungerade Zahl zugewiesen. Entsprechend bekommt Inhalt in Textform ohne Kindelement hinter dem letzten Kindelement die nächstgrößere ungerade Zahl zugewiesen. Inhalt, der nicht in Textform ist, bekommt auf dieser Ebene keine Zahl zugewiesen, ist also nur über das Elternelement referenzierbar.

Für ein Buch im Format EPUB 3 beginnt eine Referenz immer mit dem OPF-Dokument. Dort ist das Element spine immer das Kindelement von package, welches an dritter Stelle steht, bekommt also die Zahl '6' zugewiesen. Von diesem ausgehend erfolgt die weitere Referenzierung. Der Inhalt von spine besteht immer aus den Kindelementen itemref. Die Zahl für ein Kindelement steht hier immer für das damit über das zugehörige item referenzierte Dokument. '8' steht hier also für das Dokument, welches mit dem vierten Kindelement von spine referenziert wird.

Das nächste Segment des Buches ist immer ein komplettes Dokument, daher ist ein Ausrufezeichen zu notieren und die Zählung beginnt wieder mit den Kindelementen des Wurzelelementes. Handelt es sich zum Beispiel ein XHTML-Dokument, so ist das Element body immer das zweite Kindelement des Wurzelelementes. Ist nun eine Überschrift h1 darin das erste Element, so bekommt dies also die Identifizierung '6/8!/4/2'. Hat ein so referenziertes Element einen Fragmentidentifizierer, so ist dieser in eckigen Klammern anzufügen. Ist dieser für das h1 zum Beispiel 'k2', so ergibt sich für die Identifizierung '6/8!/4/2[k2]'.

Wenn es beim Notieren von freiem Text, insbesondere in diesen eckigen Klammern, Konflikte mit der Syntax gibt, so ist dem fraglichen Zeichen jeweils ein '^' voranzusetzen, also etwa für den Text 'A[Klammer]' innerhalb von eckigen Klammern: '[A^[Klammer^]]'. Betroffen sind davon die Zeichen '^', '[', ']', '(', ')', ',', ';'.
Unabhängig davon kann es notwendig sein, Zeichen nach den allgemeinen Regeln zu maskieren, wenn dies für eine IRI notwendig ist, etwa bei Leerzeichen oder aber wenn solch ein Fragmentidentifizierer als Attributwert in einem XHTML-Dokument notiert wird, sind Zeichen wie '>', '<', '&' und die verwendete Anführungszeichen natürlich entsprechend den Regeln von XML zu maskieren.

Beim Textinhalt eines Elementes kann ein Doppelpunkt einen Versatz angeben, wobei dieser dann immer auf einzelne Zeichen bezogen ist, genauer auf den Beginn eines Zeichens. '6/8!/4/2[k2]/1:11' bedeutet also das elfte Zeichen dieser Überschrift. Dabei bedeutet '0' vor dem ersten Zeichen, '1' der Beginn des ersten Zeichens, Zahlen jenseits der Länge des Textinhaltes dürfen nicht notiert werden.

Bei einem inhaltsleeren Element mit Alternativtext wie dem Element img kann dieser Text direkt über die Zahl des Elementes bezogen werden. Enthält obige Überschrift also ein Bild als einziges Element im Inhalt mit dem Alternativtext 'Heiners Wurstspezialitäten', so referenziert '6/8!/4/2[k2]/2:9' das 'W' der Wurstspezialitäten.

Als Kommentar in eckigen Klammern kann im Bedarfsfalle auch angegeben werden, welcher Text vor oder nach der angegebene Stelle folgt, also etwa '6/8!/4/2[k2]/2:14[t,sp]'. Der erste Ausdruck in der eckigen Klammer steht für die Zeichen davor, nach einem Komma folgen optional Zeichen danach. Will man keine Zeichen davor angeben, kann man den Teil vor dem Komma leer lassen.

Es kann auch festgelegt werden, ob mehr der Inhalt vor dem referenzierten Punkt relevant ist oder der danach, dazu wird in der eckigen Klammern ein Ausdruck angefügt, also etwa ';s=b' für davor, und ';s=a' für danach, insgesamt also: '6/8!/4/2[k2]/2:14[t,sp;s=b]' oder '6/8!/4/2[k2]/2:14[t,sp;s=a]'. Ohne die Buchstabenkennung: '6/8!/4/2[k2]/2:14[;s=a]' für die 'spezialitäten' und '6/8!/4/2[k2]/2:14[;s=b]' für 'Heiners Wurst'.

Gibt es hingegen als Überschrift nur 'Heiners Wurstspezialitäten' und kein Bild, so referenziert sich besagtes 'W' als: '6/8!/4/2[k2]/1:9'.

Wird hingegen statt eines img eine Audio- oder Videodatei referenziert, so kann man statt eines Doppelpunktes ein '~' verwenden, um ein Zeitdauer seit Beginn der Multimedia-Datei zu referenzieren, also etwa 71.8 Sekunden nach dem Beginn: '6/8!/4/2[k2]/2~71.8'.

Bei Bildern und Videos läßt sich auch eine Position in der Darstellungsebene angeben, dazu dient das Zeichen '@', gefolgt von zwei Zahlen, die mit einem Doppelpunkt voneinander getrennt sind. Die erste steht für die x-Richtung, die zweite für die y-Richtung. Die Zahlen liegen jeweils im Bereich von 0 bis 100, wobei 0:0 links oben ist, 100:100 rechts unten, 50:50 die Mitte, 0:100 links unten, 100:0 rechts oben etc. Insgesamt ergibt sich so zum Beispiel: '6/8!/4/2[k2]/2@30:20'.

Bei einem Video kann es ferner sinnvoll sein, sowohl die Position als auch die Zeit festzulegen, dann wird erst die Zeit, dann die Position notiert, also etwa: '6/8!/4/2[k2]/2~71.8@30:20'.

Bereich im Buch referenzieren

Es läßt sich auch ein kompletter Bereich referenzieren, etwa auch nützlich bei Quellenangaben zu Zitaten.

Die Teile eines Bereiches werden dabei mit Kommata separiert notiert. Als erster Teil (P) wird dazu der gemeinsame Elternpfad notiert, als zweiter Teil (A) der Anfang des Bereiches, als dritter Teil das Ende (E), also symbolisch: 'epubcfi(P,A,E)'.

Nehmen wir bezogen auf das Beispiel aus dem vorherigen Abschnitt an, der Rest des Dokumentes mit 'Heiners Wurstspezialitäten' bestehe aus ausreichend vielen weiteren Kindelementen von body, etwa Absätzen, und man möchte den fünften bis zehnten Absatz referenzieren. Demzufolge ist also body das letzte gemeinsame Element im Elternpfad, folglich ist P = '6/8!/4'.
Wenn ein weiteres Element auf den zehnten Absatz folgt, so kann man folglich formulieren: 'epubcfi(6/8!/4,/10:0,/22:0)'. Folgt kein weiteres Element, muß man sich zwangsläufig auf den folgenden nicht Elementbereich beziehen: 'epubcfi(6/8!/4,/10:0,/21:0)', was im Zweifelsfalle immer funktioniert.

Entsprechend läßt sich beim Beispiel aus dem vorherigen Abschnitt auch präzise die Wurst selektieren: 'epubcfi(6/8!/4/2[k2],/1:9,/1:14)'.

Die Notation für davor und dahinter ist bei Bereichen nicht zu verwenden, für den Anfang wird automatisch der Beginn direkt nach dem angegebene Punkt angenommen, für das Ende jeweils der Bereich davor.

Beispiele

Angenommen es gäbe ein Buch 'http://example.org/HFS.epub'. Dies sei das in den vorherigen Beispielen verwendete 'Heiners Wurstspezialitäten'. Darin könnten dann Inhalte referenziert werden, zum Beispiel: 'http://example.org/HFS.epub#epubcfi(6/8!/4/2[k2])'. Nachdem man solch einem Verweis gefolgt ist, findet man sich dann bei der Überschrift 'Heiners Wurstspezialitäten' wieder. Auch innerhalb des Buches kann die Stelle einfach referenziert werden: '#epubcfi(6/8!/4/2[k2])'. Das funktioniert dann unabhängig davon, wo das Buch gerade lokalisiert ist.

Entsprechend ergibt sich für die 'Wurst' dann also der Bereich: 'http://example.org/HFS.epub#epubcfi(6/8!/4/2[k2],/1:9,/1:14)'

Literaturangaben