Digitale Bücher im Format EPUB 3 selbst erstellen

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/#

Gut geeignet für Metainformationen sind etwa die Terme nach Dublin Core [DCT].

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 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>
<!-- Verschiedene Ausgaben -->
    <meta id="issued1" property="dcterms:issued">2013-01-11</meta>
      <meta refines="#issued1" property="display-seq">1</meta>
    <meta id="issued2" property="dcterms:issued">2013-06-01</meta>
      <meta refines="#issued2" property="display-seq">2</meta>
<!-- erweiterte Beschreibung (einige Händler sollen Probleme bei langen Beschreibungen machen) -->
    <dc:description id="Beschreibung">
     Kurze Beschreibung für Händler mit zum Beispiel maximal 250 Zeichen.
     In EPUB ist die Größe mitnichten festgelegt.
     Dies ist also bloß eine erratische Forderung von einzelnen Händlern!
    </dc:description>
    <meta refines="#Beschreibung" property="dcterms:description">
     … ausführliche Beschreibung in sinnvoller Länge …
    </meta>
<!-- Formale Angabe zur tatsächlich verwendeten EPUB-Version
     (praktisch nicht relevant für Prüfung, er zur eigenen Erinnerung oder für spätere Archivare) -->
    <meta property="dcterms:conformsTo">https://www.w3.org/publishing/epub32/</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'

Angabe zur Seiteneinteilung.
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.

'rendition:spread'

Art der Präsentation, Ausrichtung bei Seiteneinteilung.
Als Werte gibt es 'none' für keine spezielle Präsentation, 'landscape' spezielle Päsentation von Seiten nebeneinander lediglich im Längsformat, 'portrait' spezielle Päsentation von Seiten nebeneinander lediglich im Hochformat, 'both' spezielle Päsentation von Seiten nebeneinander, 'auto' nach Belieben des Darstellungsprogrammes (Voreinstellung, sofern die Angabe fehlt)

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>
<meta property="rendition:spread">none</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 Programmerweiterungen 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. Insbesondere umfangreichere Blöcke wie Abbildungen, Tabellen, Listen sind schwierig automatisch anzuordnen, weswegen solche Programme zur automatischen Seiteneinteilung auch regelmäßig überfordert sind. Die Idee, bei digitalen Büchern eine Anmutung eines gedrucktes Buches zu erzeugen, ist also ein Irrweg, welcher den Möglichkeiten und Vorteilen digitaler Bücher nicht gerecht wird, im Gegenteil, diese Möglichkeiten geradezu sabotiert.
Dieser Irrweg kann also gezielt ausgewählt werden, wenn folgende Angabe notiert wird:

<meta property="rendition:flow">paginated</meta>
<meta property="rendition:spread">both</meta>

Um das gesamte Buch in einer 'Schriftrolle' abzurollen, wäre also zu notieren:

<meta property="rendition:flow">scrolled-continuous</meta>
<meta property="rendition:spread">none</meta>

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. Werden width und height in anderen Einheiten als Prozentwerten, etwa in em oder mm angegeben, so ergibt sich ebenfalls eine feste Darstellung. Reicht der Darstellungsbereich nicht aus für die angegebenen Größen, erfordert dies folglich ebenfalls ein Rollen oder Verschieben, um nicht sichtbare Teile des Inhaltes zugänglich zu machen. Anders als typisch für XHTML erfolgt dies dann nicht nur vertikal, meist ebenfalls horizontal.

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 bei XHTML-Dokumenten mit Text darin benötigt wird.

Dabei ist ferner zu beachten, daß insbesondere Verkleinerungen des Inhaltes die Lesbarkeit für den Nutzer verschlechtern können. Der Inhalt kann dabei auch komplett unlesbar werden. Ein Darstellungsprogramm sollte also immer eine Lupen- oder Vergrößerungsfunktion verfügbar machen können, um Teilbereiche wieder lesbar und erkennbar zu machen. Dies Vorgehen kann bei Karten und Graphiken noch gut sein, bei umfangreicherem Text sicherlich nicht.

Genaugenommen 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.
Hier bleibt bei EPUB nur die allgemeine Forderung an Darstellungsprogramme, barrierefrei und zugänglich zu sein, ein Abschneiden von Inhalten ist also keine Option. Gelegentlich ist bei mangelhaften Programmen mit dem Versuch einer Anmutung von Seitendarstellung mit zwei Seiten nebeneinander auch zu beobachten, daß breite Objekte wie etwa lange Wörter dann seitlich auf die nächste Seite überlappen, so den Text gleich an zwei Stellen unlesbar machen. Auch dies ist keine zulässige Präsentation im Sinne von Barrierefreiheit und Zugänglichkeit.

property mit dem Wert 'rendition:layout' kann notiert werden, um das Layout für das gesamte Buch festzulegen. Der Wert 'reflowable' repräsentiert 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. Jedes Inhaltsdokument entspricht dabei genau einer Seite.

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. Ein inch oder cm in CSS hat also allenfalls beim Ausdrucken etwas mit dem internationalen Standard-Längenmaß Meter etwas zu tun. Dieser Wildwuchs und Unfug ist der CSS-Arbeitsgruppe des W3C leider bislang nicht auszureden gewesen. In digitalen Büchern sollte man daher absolute Maßangaben wie inch, cm, Pixel vermeiden.
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 dürfen soll, wie dies etwa em oder ex wären, 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.
Auch hier bleibt selbstverständlich die allgemeine Forderung von EPUB an Darstellungsprogramme gültig, Inhalte zugänglich zu machen. Wie dies geschieht, kann von Programm zu Programm verschieden sein. Weil Programme oft mangelhaft sind und nicht barrierefrei sind, ist damit zu rechnen, daß bei solchen überstehenden Inhalte einfach unzugänglich sind.

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 vorneherein 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"/>

Element link

Neu in EPUB 3 ist das inhaltsleere Element link. Dieses dient dazu, (externe) Datensätze mit Metainformationen zum Buch oder anderen Metainformationen zum Buch wie etwa den Autoren zu referenzieren, etwa auch eine Netz-Präsenz zum Buch oder Autor. Darstellungsprogramme für EPUB 3 brauchen solche Referenzierungen aber nicht zu verarbeiten, anzuzeigen oder sonstwie verfügbar machen. Solche Einträge sind also eher für Spezialprogramme und Bibliothekare, die das Archiv auseinandernehmen, um an die Einzeldaten zu kommen.

Dies kann auch nützlich sein, um auf ein maschinenlesbares Dokument zu verweisen, in welchem eindeutig Lizenzen oder Autorenschaften von Buchfragmenten strukturiert verzeichnet sind, welche wiederum auf die betreffenden Dokumente im Buch verweisen, dazugehörige Lizenzinformationen liefern oder auf einen externen Eintrag dafür verweisen. Darauf basierend könnten dafür geeignete Programme also nachvollziehen, ob Inhalte aus anderen Quellen mit einer berechtigenden Lizenz verwendet werden. Mit welchem Format dies eindeutig machbar ist, welche Programme diese Informationen dies ernsthaft automatisch korrekt interpretieren könnten, ist indes nicht Gegenstand dieser Anleitung.
Derartige Angaben werden jedoch einerseits zunehmend dringlich wegen aufkommender Filter beim Hochladen von Büchern, welche zwangsläufig ohne eine Interpretation derartiger Angaben sehr oft fehlerhafte Sperrungen vornehmen werden, was effektiv eine grundlose Zensur durch automatisierte Dummheit bedeutet. Andererseits hat es die Arbeitsgruppe zu EPUB nach einer diesbezüglichen Nachfrage abgelehnt, sich darum zu kümmern, solche Angaben normativ in einer Empfehlung festzuschreiben.

Das erforderliche Attribut href dient dazu, die Ressource zu referenzieren, der Wert ist also eine absolute oder relative URI oder IRI. Dokumente die zum Buch gehören, also im manifest gelistet sind, dürfen so nicht referenziert werden.

Mit dem erforderlichen Attribut rel wird die Relation angegeben, also wie der Zusammenhang der Ressource entweder mit dem Buch ist oder mit einer verfeinerten Metainformation, sofern das Attribut refines angegeben ist. Der Wert ist eine CURIE.

Mit dem optionalen Attribut refines kann angegeben werden, worauf sich die Relation bezieht, der Wert ist ein relative URI oder ein Fragmentidentifizierer eines Metainformationselementes. Ist das Attribut nicht angegeben, liegt ein Bezug zum gesamten Buch oder Archiv vor.

Mit dem Attribut media-type kann der Medientyp der referenzierten Ressource angegeben werden.

Ferner kann ein Attribut id notiert werden, mit der üblichen Funktion eines Fragmentidentifizierers.

Für rel gibt es auch noch vordefinierte Werte, die ohne Präfix verwendet werden können:

'marc21xml-record'

Ein MARC21-Datensatz

'mods-record'

Ein MODS-Datensatz

'onix-record'

Ein ONIX-Datensatz

'xmp-record'

Ein XMP-Datensatz

'xml-signature'

Eine XML-Signatur

'record'

Neu in Version 3.0.1; Meta-Datensatz, mittels media-type ist dann der Typ anzugeben

'acquire'

Erst im Stadium eines Arbeitsentwurfs in Version 3.0.1; nur relevant, wenn es sich beim aktuellen Buch um eine Vorschau für ein anderes, komplettes Buch handelt; die Spezifikation für solche Vorschaubücher ist allerdings auch erst im Stadium eines Arbeitsentwurfes, wird hier also nicht weiter erläutert

Die Referenzen zu den Spezifikationen zu den einzelnen Datensätzen und der Signatur sind jeweils der Spezifikation zu entnehmen [Ds]. Beispiele mit vordefinierten Präfixen:

<link rel="marc21xml-record" href="http://example.org/marc/eb3035a7-d3ff-476f-8fb5-da335893873b"/>
<link rel="onix-record" href="http://example.org/onix/eb3035a7-d3ff-476f-8fb5-da335893873b"/>
<link rel="xmp-record" href="http://example.org/xmp/eb3035a7-d3ff-476f-8fb5-da335893873b"/>
<link rel="mods-record" href="http://example.org/mods/eb3035a7-d3ff-476f-8fb5-da335893873b"/>
<link rel="xml-signature" href="http://example.org/sig/eb3035a7-d3ff-476f-8fb5-da335893873b"/>

Elemente nach Dublin Core

Der sonstige Inhalt von metadata besteht also aus dem Basissatz der 15 Elemente von Dublin Core. Ergänzungen oder 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">
<!-- Eindeutige Buchidentifikation, hier mit einer EBI -->
    <dc:identifier 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 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/">
<!-- Eindeutige Buchidentifikation, hier mit einer UUID -->
    <dc:identifier id="id">eb3035a7-d3ff-476f-8fb5-da335893873b</dc:identifier>
    <meta property="identifier-type" refines="#id">UUID</meta>
<!-- Der Buchtitel -->
    <dc:title 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 id="id_sub" xml:lang="de">Öffentliche Kunst in Hannover</dc:title>
    <meta refines="#id_sub" property="title-type">subtitle</meta>
    <meta refines="#id_sub" 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. Weil 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 notieren.

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 jedoch 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/">
  <!-- ... andere Metainformationen ...-->
  <dc:creator 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.

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'; neu: 'font/ttf' beziehungsweise 'font/otf'

Schriftartendatei; eine generische Schriftfamilie ist allerdings immer als Alternative anzugeben

'application/font-woff'; neu: '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. Die Behauptung 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. Bei Pixel-Formaten für Bilder und Videos und für Audio-Dateien ist es ohnehin notwendig, Textalternativen bereitzustellen, um Zugänglichkeit sicherzustellen.

Beispiel für die Angabe einer Alternative im Falle von Schriftartendateien im manifest:

<item href="MeinFont.ttf" id="ttf" media-type="font/ttf" fallback="woff"/>
<item href="MeinFont.otf" id="otf" media-type="font/otf" fallback="woff"/>
<item href="MeinFont.woff" id="woff" media-type="font/woff" fallback="svgfonts"/>
<item href="MeineFonts.svg" id="svgfonts" media-type="image/svg+xml"/>

Problematisch für das Konzept von EPUB ist hier, daß lediglich Dokumente angegeben werden können, eine Schriftart in SVG als Kernmedientyp ist allerdings eigentlich ein Fragment in dem Dokument, eigentlich wäre also der Fragmentidentifizierer anzuhängen, was in den referenzierenden CSS-Dateien auch passiert. Dort wird zum Beispiel auf 'MeineFonts.svg#F1' verwiesen, denn 'MeineFonts.svg' kann mehrere Schriftarten und auch andere Inhalte enthalten.

Unschön ist ferner die Angabe für media-type bei Schriftartendateien. Die Werte sind in der EPUB-Spezifikation teilweise noch anders angegeben, als diese nun offiziell festgelegt sind. So gibt die EPUB-Spezifikation für das Format WOFF etwa noch 'application/font-woff' an.

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. Weil 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. Weil 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.