Wenn beim Export eine Titelei vorhanden ist, diese aber nicht einer in der zugehörigen Dateiname_LIGHT_META.xml vorhandenen <ausgabe> zuzuordnen ist, wird eine Warnung ausgegeben:
[Warnung] Die exportierte Titelei konnte der Ausgabe mit der ID "ausgabe-2" nicht zugeordnet werden und wird auskommentiert übernommen.
Dies ist z.B. der Fall, wenn die Titelei erst in InDesign erstellt und getaggt wird oder wenn die Dateiname_LIGHT_META.xml nicht gefunden wird.
Wie beschrieben wird die Titelei am Anfang des <werk>-Elements auskommentiert in die parsX 4-Datei übernommen und muss dann manuell in ein entsprechendes <ausgabe>-Element gesetzt werden.
Wenn die zugehörige Dateiname_LIGHT_META.xml (s.o.) nicht gefunden wird oder beschädigt wurde, können Container-<meta>-Elemente nicht zurückgeschrieben werden:
[Warnung ] Das [meta]-Element für [einschub1] wurde nicht gefunden!
Wenn eine Datei mit einer ausgelagerten MathML-Formel (s.o.) fehlt oder umbenannt wurde, kann ein <m:math>-Element nicht wieder eingefügt werden:
[Saxon-PE] [Warnung] Das MathML-Element für die [formel] wurde in der Datei: C:/Users/…/Dateiname-formeln/Formel-d358.mml nicht gefunden! Es wird nur die Abbildung als Inhalt übernommen.
Seit parsX 4.3.9 können verschachelte Listen (mit einem neuen Attribut @ebene an den Listenabsätzen) und Zuweisung von Absatzformatvarianten beim XML-Import verarbeitet werden (s. die Erläuterungen zu XML-Elementen und Strukturen in der Light-DTD zu Listen). Dabei werden Sprünge in der Hierarchie (z.B. Ebene 4 folgt auf Ebene 3) nicht unterstützt. Nach dem Import entsprechen die @ebene-Attribute dieser Vorgabe.
Sollten sich im Satz Änderungen ergeben, werden bei der Rücktransformation die folgenden Fälle gemeldet:
Die Liste beginnt auf Ebene 1, aber dann wird eine Ebene übersprungen:
Die eingeschachtelte Liste rückt eine Ebene auf. Meldung:
[Info] In der Liste werden Ebenen übersprungen (1→3). Bitte prüfen Sie die Listenstruktur.
Die Liste beginnt mit einer tieferen Ebene (z.B. weil in eine Liste der Ebene 2 ein Absatz Grundtext eingfügt wurde), und zwar:
Die Liste beginnt nicht auf Ebene 1, es es folgen aber keine Elemente einer höheren Ebene.
Die gesamte Liste rückt auf Ebene 1 auf. Meldung:
[Info] Die Liste beginnt mit Ebene 2 statt 1. Bitte prüfen Sie die Listenstruktur.
Es folgen in derselben Liste noch Elemente auf höherer Ebene (z.B. am Ende Elemente der Ebene 1, evtl. eine Legende)
Der Container für die Elemente höherer Ebene wird gesetzt, enthält aber vor der nächsten Liste keine Elemente (invalide!). Meldung:
[Warnung] Die Liste beginnt mit Ebene 2 statt 1. Die Struktur wird dadurch invalide!
Seit parsX v4.0.5 ist es möglich, mehrstufige statische Verzeichnisse (<inhaltsverzeichnis>, <verzeichnis> und <index>) zu im- und exportieren. Näheres im Abschnitt zum Import.
[Warnung] Das [inhaltsverzeichnis] beginnt mit Ebene 2 statt 1.
[Warnung] Im [inhaltsverzeichnis] wird eine Ebene übersprungen (2→4)
Das Überspringen von hierarchischen Ebenen (in parsX 4 mit dem Attribut <ebene-ueberspringen="ja">) wird derzeit nicht unterstützt. Ein erster Eintrag auf Ebene 2 (z.B. "Vorwort" im Inhaltsverzeichnis) wird daher als Ebene 1 exportiert, eine <u4>, die auf eine <u2> folgt als Eintrag 3. Ebene.
Statische Glossare (<liste_definition typ="glossar">) können im- und exportiert werden.
Außerdem ist es möglich, eine beim Import aus <definition>-Elementen generierte <liste_definition typ="glossar"> im Satz zu bearbeiten und als statisches Glossar wieder zu exportieren (Dies ist im Abschnitt zum Import genauer beschrieben).
Wenn dabei ein Eintrag per Copy/Paste dupliziert und bearbeitet wurde, kann es zu folgender Warnmeldung kommen:
Aus dem Glossar wird auf das [definition]-Element mit der ID "elNr-1-2-1-1-6-1-1" mehrfach verwiesen. Dies ist wahrscheinlich ein Copy/Paste-Fehler und kann bei der Rücktransformation invalide Strukturen erzeugen.
In generierten Glossaren wird ein Verweis vom Glossar-<eintrag> auf das zugehörige <definition>-Element im Text gesetzt (in der Regel das erste Vorkommen des erklärten Begrigffs). Durch die Kopie verweisen nun zwei verschiedene Glossareinträge auf dasselbe <definition>-Element.
Dies führt im exportierten XML dann zu einem Validierungsfehler, wenn die die Definitionen nicht als Marginalien ausgegeben werden. In diesem Fall werden die Definition-Elemente im Text aus dem Glossar wiederhergestellt und es entsteht ein <definition>-Element mit zwei <eintrag>-Elementen – was nicht zulässig ist.
Im EBook kann mit den Verweisen aus dem Glossar an die entsprechennde Stelle im Text gesprungen werden, daher sollte für einen neuen Eintrag im Glossar auch ein zugehöriges neues <definition>-Element erstellt werden.
Seit parsX 4.3.9 kann ein beim Import generiertes Glossar mit auf die entsprechenden Einträge verlinkten Fundstellen exportiert werden. Dazu muss ein Attribut am Wurzelelement <projekt_indd> gesetzt werden, s. Neuerungen parsX 4.3.9 Plugin. In dieseem Fall erscheint die Meldung:
[[ Info ] | Glossarfundstellen werden verlinkt.
Folgende Meldungen können bei der Rücktransformation von XML-Daten mit Registermarkierungen auftreten:
[Warnung] Es kommen mehrere Registerarten als Typ-Attribut an [register-eintrag] vor: "sach" (1758x), "person" (738x).
Hier wurden im Satz Registermarkierungen nachgetaggt und dabei ein abweichender Registertyp gesetzt (z.B. "person" statt "sach"). Da mehrere Register bei Export und Weiterverarbeitung (z.B. E-Book) kein Problem darstellen, ist dies durchaus möglich. Ein grobes Missverhältnis der Anzahlen, z.B. "sach" (1758x), "person" (3x), weist auf Taggingfehler im Satz hin.
[Info] Registerart ist nicht mit Typ-Attribut an [register-eintrag] definiert, wird als Sachregister umgesetzt.
Bei einer im Satz nachgetaggten Registermarkierung wurde kein Typ-Attribut an <register-eintrag> gesetzt. Wenn der Typ der übrigen Einträge einheitlich ist, wird dieser verwendet, ansonsten wird der Registereintrag als Sachregister umgesetzt und diese Meldung ausgegeben.
[Warnung] Für den Register-Eintrag Typ "sach": "Kopenhagen" sind unterschiedliche Sortierschlüssel definiert. Es wird der erste vorkommende: "Copenhagen" verwendet.
Beim Import wurden ggf. abweichende Angaben im Attribut @sortierung für den gleichen Registerbegriff vereinheitlicht. – Hier wurde also im Satz ein Begriff manuell umsortiert, die Änderung aber nicht in die XML-Struktur an alle betreffenden Registermarkierungen im Dokument übertragen.
Folgende Meldung kann beim Export von Daten mit dem <inline_container> auftreten:
[Warnung] Inline-Typ für den Text "Beispieltext" in [inline_container] Typ "1" wurde im Satz geändert!
Wird im Satz für Text in einem <inline_container> die Schriftauszeichnung geändert, so dass das zugewiesene Zeichenformat nicht mehr den Inline-Typ des Containers enthält (also z.B. kursiv statt inline10_kursiv, entsteht bei der Rücktransformation ein Konflikt.
Nach der Rücktransformation
wird der <inline_container> in jedem Fall in ein <inline>-Element mit dessen Attributen (einschließlich des Typs) umgewandelt,
wird ein abweichendes <inline>-Zeichenformat darin zu einem eingeschachtelten <inline>-Element (doppelte Inline-Auszeichnung).
Wurde im Satz die <inline>-Schriftauszeichnung gelöscht, so geht diese Information bei der Rücktransformation verloren: z.B. werden kursiv und inline10_kursiv innerhalb eines <inline_container>s vom Typ 10 nicht unterschieden.