Wir stehen vor Datentransformationsprojeken nach MARC-XML.
Wie geht man da in MARC-XML mit den datensatzbezogenen Informationen im Leader um:
Character Positions 00-04 - Record length
Pos. 12-16 - Base address of data
Position 00-04 scheint ja ein Relikt aus Datenbänder-Zeit zu sein. Wären die Zeichen in Binär Marc ermittelbar ist, lässt sich das nicht ohne weiteres mit der Zeichenzahl in einem XML-MARC Datensatz vergleichen. Die weichen ja von einander ab.
Ist der Wert in Pos. 00-04 daher bedeutungslos für MARC-XML? Was trägt man da am besten ein?
Bei Pos. 12-16 - Base address of data wüsste ich auch nicht, was wir darin eintragen müssten, oder ob die für MARC-XML keine Relevanz mehr haben. Was trägt man also an die Stelle ein, oder lässt man die leer?
„Allerdings sind einige Datenfelder des Leaders für die Repräsentation im MARCXML-Format nicht relevant; beispielsweise hat die Größe des Datensatzes für verarbeitende Software keine Bedeutung mehr, da sich diese aus dem Aufbau der XML-Struktur ergibt und ohnehin von der Größe des zugehörigen MARC-21-Datensatzes abweicht. Diese Teile des Leaders dürfen beliebig“
Mit Referenz auf "Cole & Han (2013, Chapter 4, S. 79).
in: Wolfgang Boiger: Entwicklung und Implementierung eines MARC21-MARCXML-Konverters in der Programmiersprache Perl (Perspektive Bibliothek 4.2 (2015), S. 33-59) hier: S.38
Ganz korrekt wäre es, wenn hier an den genannten Positionen die Werte stehen würden, die auch in der ISO 2709 Repräsentation des Datensatzes im Leader stehen. Tatsächlich aber ist das in der Praxis wirklich irrelevant - für XML sowieso aber auch für Parsen eines ISO 2709 Records braucht man diese Werte nicht explizit zu kennen, sondern kann sie aus dem Vorkommen der Steuerzeichen x1E und x1D jeweils berechnen (soweit ich das übersehe ist das das, was die meisten Tools tun.)
Ich habe nochmal die Referenz gefunden, auf den sich mein Zitat oben bezieht:
„The construction of the element in a MARCXML record has some minor nuances. Typically, a MARCXML element takes, as content, the leader string unchanged from the way it would appear in a traditional MARC record serialization for magnetic tape, including any spaces. However, implementers should recognize, especially when creating MARCXML records from scratch rather than transforming existing MARC records, that a few character positions of the element are ambiguous in a MARCXML serialization. In traditional MARC, the first five characters of the leader string (character positions 0 to 4) are meant to hold the length of the record. They can be used for this purpose in MARCXML, but XML-applications processing MARCXML records do not use this information; they have other (more reliable) options to determine the „length of an XML-serialized MARC record or to move on to the next element in a MARCXML instance. If transformed from a traditional MARC record, these first five characters often are left as is (i.e., representing the length of the record when it was serialized according to the tape-based traditional MARC record format). In other instances, these first five characters of the leader may be set to all zeros in the MARCXML record (the authors’ personal preference). Similar logic is applied to leader character positions 12 to 16, which are designed to hold the base address for a traditionally serialized MARC record on tape. Finally, leader character positions 20 to 23 make up the entry map for the MARC record directory. Since directory entries are not relevant to the MARCXML serialization of the record, these character positions are either left as they would appear in the traditional MARC serialization (always “4500”) or left blank (i.e., four spaces).“
// Initialisierung mit der Länge des zu generierenden Leaders selbst,
// d.h. 24 für die Länge des Leaders
// + 1 record terminator
// + 1 field terminator after the leader and directory
recordLength = 26;
// für jeden generierenden Knoten mit Werten:
recordLength += value.toString().length;
// Schlussendlich das ganze Beiwerk darumherum noch addieren
// controlfields: 12 characters in the directory + 1 field terminator
// datafields: 12 characters in the directory + 2 indicators + 1 field terminator
// subfields: 1 subfield code + 1 subfield terminator
recordLength += countFields.controlfield*13+countFields.datafield*15+countFields.subfield*2;
Ich würde mal behaupten, dass dies dann für mich „genügend gut“ funktioniert hat, aber es ist schon eine Weile her, dass ich dies so umgesetzt habe.