Spreadsheet XML für Excel, Calc & Co.

Das „Standard-Auswertungswerkzeug“ für Daten ist „Excel“, „Calc“ oder eines der ungezählten Derivate, die alle auf den Urvater aller Tabellenkalkulationen, „Lotus 1-2-3“ zurück gehen.

Mittlerweile können Daten zumindest zwischen den bekannteren Protagonisten relativ unproblematisch ausgetauscht werden. Das „Daten rein kriegen“ erfolgt bei allem Fortschritt im Datenaustausch dennoch überwiegend im CSV-Format. Für große Datenmengen ist es ein bequemes Format: Lesbar, schlicht strukturiert, problemlos mit Software oder Messgeräten erzeugbar.

Schwieriger wird es, wenn die Daten Berechnungen enthalten sollen. Grundsätzlich geht das durchaus in CSV-Dateien. Dieser Import „rechnet“:

Alle Beispiele können am Seitenende als Archiv herunter geladen werden.

1;2;3
=B2+A1;=C1*B1
=A2*B2

Das ist „gut lesbar“, doch diese simple CSV-Datei erfordert bereits eine solide Vorstellungskraft, was in „A3“ herauskommt – und wo diese Zelle ist.

XML ist keineswegs lesbarer. Doch hat dieses Format einen Vorteil gegenüber CSV: es erlaubt „Gestaltung“. Das SpreadsheetXML-Format ermöglicht mehr als „Zahlen und Formeln“. Die meisten Beschreibungen dafür haben leider eine unnötige Komplexität, die vom Wesentlichen wegführt.

Diese Erkenntnis stammt aus der Auseinandersetzung mit diesem Format für den Datenexport aus meiner Projekterfassung. Dafür wurde das generierte XML auf das Wesentliche reduziert. Das Meiste in Beispielen und der Dokumentation ist nämlich für die Datenübergabe schlicht überflüssig.

Die Basis-Struktur

<?xml version="1.0"?>
<Workbook xmlns="urn:schemas-microsoft-com:office:spreadsheet"
 xmlns:o="urn:schemas-microsoft-com:office:office"
 xmlns:x="urn:schemas-microsoft-com:office:excel"
 xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet"
 xmlns:html="http://www.w3.org/TR/REC-html40"
 xml:lang="de">

Dieser Header ist erforderlich, damit Excel die Datei akzeptiert. Aufgrund der Verbreitung im gewerblichen Bereich ist das eine gesetzte Bedingung, LibreOffice Calc importiert damit ebenfalls. Wie andere Kandidaten sich verhalten ist ungetestet.

<Styles>
<Style ss:ID="d1">Formatbeschreibung</Style>
…
</Styles>

Es folgt ein „Style-Sheet“, das lediglich „IDs“ kennt. Was irreführend ist. Eine ID ist typischerweise eindeutig. Hier funktionieren sie wie „Klassen“ in einer CSS-Datei.

<Worksheet ss:Name="Arbeitsblatt">
<Table>
<Row>
	<Cell><Data ss:Type="String">Titelzeile</Data></Cell>
	<Cell><Data ss:Type="Number">1</Data></Cell>
</Row>
 
<Row>
	<Cell ss:StyleID="d1"><Data  ss:Type="DateTime">2021-12-10</Data></Cell>
   <Cell ss:StyleID="d3" ss:Formula="=…"></Cell>
	…	
</Row>
<Row/>
</Table>
</Worksheet>
</Workbook>

Das ist die Kernstruktur: Ein Dokument besteht aus wenigsten einem Arbeitsblatt <Worksheet>, in dem eine Tabelle <table> steht. Die Besteht aus Zeilen <Row>, in denen Zellen <Cell> stehen. Formeln werden „relativ“ adressiert: RC ist die aktuelle Zelle, mit [+-Wert] wird von dort aus der gewünschte Zelleninhalt über den „Offset“ zu Spalte und Zeile angesprochen.

Je nach Bedarf kommt alles entsprechend häufig an der entsprechenden Stelle vor.

Das anfängliche CSV-Beispiel als Spreadsheet:

<?xml version="1.0"?>
<?mso-application progid="Excel.Sheet"?>
<Workbook xmlns="urn:schemas-microsoft-com:office:spreadsheet" 
 xmlns:o="urn:schemas-microsoft-com:office:office"
 xmlns:x="urn:schemas-microsoft-com:office:excel"
 xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet"
 xmlns:html="http://www.w3.org/TR/REC-html40">
 
 <Worksheet ss:Name="Der Sinn">
  <Table>
   <Row>
    <Cell><Data ss:Type="Number">1</Data></Cell>
    <Cell><Data ss:Type="Number">2</Data></Cell>
    <Cell><Data ss:Type="Number">3</Data></Cell>
   </Row>
   <Row>
    <Cell ss:Formula="=RC[1]+R[-1]C"></Cell>
    <Cell ss:Formula="=R[-1]C*R[-1]C[1]"></Cell>
   </Row>
   <Row>
    <Cell ss:Formula="=R[-1]C*R[-1]C[1]"></Cell>
   </Row>
  </Table>
 </Worksheet>
</Workbook>

Ob das verständlicher lesbar ist, liegt im Auge des Betrachters. Doch üblicherweise werden deratige Daten automatisiert erzeugt. Dabei kann dieses Format im Gegensatz zu CSV zusätzlich Einfluss auf die Darstellung in der Tabellenkalkulation nehmen:

 <?xml version="1.0"?>
<?mso-application progid="Excel.Sheet"?>
<Workbook xmlns="urn:schemas-microsoft-com:office:spreadsheet"
 xmlns:o="urn:schemas-microsoft-com:office:office"
 xmlns:x="urn:schemas-microsoft-com:office:excel"
 xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet"
 xmlns:html="http://www.w3.org/TR/REC-html40">
 
 <Styles>
  <Style ss:ID="d1"><Font ss:Color="#158466" ss:Bold="1"/></Style>
  <Style ss:ID="d2"><Font ss:Color="#FF972F" ss:Bold="1"/></Style>
  <Style ss:ID="d3"><Font ss:Color="#C9211E" ss:Bold="1"/></Style>
 </Styles>
 <Worksheet ss:Name="Der Sinn">
  <Table>
   <Row>
    <Cell ss:StyleID="d1"><Data ss:Type="Number">1</Data></Cell>
    <Cell ss:StyleID="d1"><Data ss:Type="Number">2</Data></Cell>
    <Cell ss:StyleID="d1"><Data ss:Type="Number">3</Data></Cell>
   </Row>
   <Row>
    <Cell ss:StyleID="d2" ss:Formula="=RC[1]+R[-1]C"></Cell>
    <Cell ss:StyleID="d2" ss:Formula="=R[-1]C*R[-1]C[1]"></Cell>
   </Row>
   <Row>
    <Cell ss:StyleID="d3" ss:Formula="=R[-1]C*R[-1]C[1]"></Cell>
   </Row>
  </Table>
 </Worksheet>
</Workbook>

Das ist ein bewusst schlichtes Beispiel. Für „etwas schicker mit Formeln“ ist der Aufwand überschaubar, die Präsentation der Daten in der Tabellenkalkulation lässt sich damit deutlich verbessern.

Ein weiterer Vorteil: Die „relative Adressierung“ vereinfacht beispielsweise Zeilensummen, weil keine eindeutigen Zelladressen generiert werden müssen. Für Spaltensummen genügt ein Zähler für die Anzahl der generierten Zeilen:

<Cell ss:StyleID="w1" ss:Formula="=sum(R[-5]C:R[-1]C)"></Cell>

Insbesondere erübrigt sich herauszufinden, ob die Spalte „C“ in der jeweiligen Formel „Z“ oder „AA“ heißt.

Tipp:

Bei Zugriffsmöglichkeit auf Excel führt das „heraus fummeln“ von Funktionen per Export als „XML-Kalkulationstabelle 2003“ mutmaßlich erheblich schneller zum Ziel, als das Studium von 600+ Seiten verklausulierter Dokumentation.