Spezifikation des OpenPortfolio-Formats
- Jörg Henne
- David Werth
- Former user (Deleted)
- Dennis Benedikt (Deactivated)
Diese Spezifikation beschreibt ein Datenformat, das von jadice generiert und verarbeitet wird. Die entsprechenden Produktbestandteile besitzen derzeit jedoch keine öffentliche API und dürften deshalb nur mit ausdrücklicher Genehmigung von levigo verwendet werden.
Jegliche anderweitige Verwendung erfolgt auf eigene Gefahr. Insbesondere behält sich levigo das Recht vor, Funktionen, die dieses Format betreffen jederzeit zu ergänzen, zu entfernen oder die Schnittstellen ohne Wahrung von Rückwärtskompatibilität zu verändern.
Ãœberblick
Das OpenPortfolio-Format hat das Ziel, einen portablen Standard für den Austausch und den Transport von zusammengesetzten Dokumenten zu schaffen. OpenPortfolios sind konzipiert für Anwendungen, bei denen Daten für kurze (Sekunden) bis mittlere Zeiträume (wenige Tage) vorgehalten werden müssen. Sie sind nicht gedacht und geeignet für die Langzeitspeicherung von Daten über längere Zeiträume hinweg.
OpenPortfolios bestehen aus folgenden Elementen:
- Rohdaten der Teildokumente in beliebigem Format. Quelle und Ziel eines Austauschs über OpenPortfolio müssen sich im Voraus über die zulässigen Dokumentformate einig sein.
- Informationen über den Aufbau des zusammengesetzten Dokuments, d.h.
- Auswahl, und Reihenfolge der der Seiten
- Zuordnung der Ebenen
- Metadaten (XML) zu Dokumenten und anderen Teilen des Datenmodells
- Benutzerdefinierte Eigenschaften zu Dokumenten und anderen Teilen des Datenmodells
OpenPortfolios haben folgende Eigenschaften:
- sie bestehen aus einem einzigen Datenstrom
- sie besitzen eine einfache, definierte Struktur
- sie sind sprach- und plattformneutral verarbeitbar
- sie stellen geringe Anforderungen an verfügbare Bibliotheken (dies gilt nicht für die Verarbeitung der enthaltenen Teildokumente)
- Implementierungen können unabhängig erfolgen
- levigo stellt die Spezifikation lizenzkostenfrei zur Verfügung (CC0)
Datenmodell
OpenPortfolios basieren auf folgendem Datenmodell:
Die einzelnen Elemente haben folgende Funktion:
| Element | Funktion |
|---|---|
| OpenPortfolio | Wurzelobjekt eines Portfolios |
| Page | eine einzelne Seite des zusammengesetzten Dokuments |
| PageSegment | eine Ebene innerhalb der Seite eines zusammengesetzten Dokuments; verweist auf Seite eines Teildokuments |
| Stream | ein Datenstrom, der ein Teildokument transportiert |
| Metadata | Metadaten in XML-Form |
| Properties | Benutzerdefinierte Eigenschaften (Schlüssel-Wert-Paare) |
Aufbau
Ein OpenPortfolio wird immer in einem einzigen, kompakten Datenstrom transportiert, egal, welche Daten oder Teildokumente darin enthalten sind. Es hat folgenden Aufbau:
Die einzelnen Elemente haben folgende Funktion:
| Element | Funktion |
|---|---|
| Container | Der Container dient der Verpackung der einzelnen Bestandteile des OpenPortfolios, sodass dies als kompakter Datenstrom gespeichert und transportiert werden kann. Je nach Anwendung können verschiedene Container-Formate verwendet werden. Derzeit ist lediglich ein einziges, auf ZIP basierendes Format definiert. |
| Manifest | Das Manifest besteht aus einer XML-Datei, die den Aufbau des Portfolios beschreibt. Sie enthält alle Elemente des oben genannten Datenmodells außer der Nutzdatenströme. |
| Stream 1..n | Die Nutzdaten der Teildokumente in ihren jeweiligen Formaten. Grundsätzlich erlauben es OpenPortfolios, die Nutzdaten separat zu transportieren. Hierzu ist die Verwendung entsprechender URLs in den href-Attributen der Streams zu verwenden. Levigos Implementierungen nutzen diese Möglichkeit derzeit jedoch nicht. |
Manifeste
Das Manifest beschreibt den Aufbau des Portfolios Es enthält alle Elemente des oben beschriebenen Datenmodells außer der eigentlichen Nutzdatenströme.Â
XML-Schema
Das Manifest ist ein XML-Dokument, das dem dem in open-portfolio.xsd spezifizierten Schema folgt. Es benutzt den Namensraum http://xml.levigo.com/ns/open-portfolio/1.0. Wurzelelement ist das Element <portfolio>. Details zu den einzelnen Elementen des Manifests sind in der XSD-Spezifikation als Dokumentationselemente hinterlegt. Manifeste müssen immer mit einem korrekten Namensraum deklariert werden.
Anmerkungen zum Manifest-Schema:
Das Manifest-Schema benutzt den von SOAP bekannten MTOM-Mechanismus, um auf die Nutzdaten zu verweisen. Hierzu importiert es das vom W3C herausgegebene Schema http://www.w3.org/2004/08/xop/include (xop_include.xsd).
- Metadaten werden ohne weitere Spezifikation des Aufbaus eingebettet. Hierzu ist das
<metadata>-Element als beliebige Sequenz von Elementen aus dem Wildcard-Namensraum##anydefiniert. - Benutzerdefinierte Eigenschaften sind als Schlüssel-Wert-Paare modelliert, wobei der Schlüssel jeweils ein String sein muss, der im
name-Attribut des<property>-Elements transporiert wird. - Die Werte der Properties sind mit einem umfangreichen Datenmodell abgebildet, das es erlaubt, verschiedene Datentypen unter Erhalt der Typsicherheit zu transportieren. Die Definition der Elemente greift weitgehend auf Standard-Typen der XSD-Definition zurück. Verfügbare Datentypen sind:
- Zeichenketten:
string - Numerisch:
int/long/short/byte/decimal/float/double - Wahrheitswert:
boolean - Datum/Uhrzeit:
timestamp - Maps, Kollektionen:
list/set/map
- Zeichenketten:
Container
Der Container sorgt dafür, dass alle Bestandteile eines OpenPortfolios als kompakter Datenstrom transportiert werden können. Je nach Anwendung können verschiedene Container-Formate verwendet werden. Derzeit ist jedoch lediglich ein einziges Container-Format spezifiziert. Dieses basiert auf dem Format von ZIP-Archiven und ist somit sehr einfach mit den entsprechenden Bibliotheken erzeugbar bzw. lesbar.
ZIP-Container-Format
Das ZIP-Container-Format basiert auf dem bekannten Format von ZIP-Archiven, erfordert jedoch die Einhaltung eines bestimmten Aufbaus.
Aufbau
OpenPortfolios im ZIP-Container-Format müssen folgender Struktur genügen:
| Dateiname | Anzahl | Inhalt | Anmerkungen |
|---|---|---|---|
| OPEN-PORTFOLIO | 1 | Versionsnummer der Spezifikation, derzeit "1.0" | Muss zwingend die erste Datei im Portfolio sein, um zur Identifikation nicht das gesamte ZIP, das sein Inhaltsverzeichnis immer am Ende hat, lesen zu müssen. |
| MANIFEST | 1 | Das Manifest | Kann an beliebiger Stelle nach der Versionsnummer-Datei kommen |
| STREAM.<id> | 1..* | Nutzdatenstrom der ID <id> | Die ID des Datenstroms korrespondiert jeweils mit einer CID einer XOP-Referenz |
Die XOP-Referenzen für das ZIP-Container-Format müssen folgende Form aufweisen:
<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:<id>"/>
Jadice verwendet bei der Generierung fortlaufende numerische IDs. Somit heißt der erste Stream STREAM.1 und wird als <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:1"/> referenziert. Implementierungen sind bei der Wahl ihrer IDs frei, diese müssen jedoch den Anforderungen für Dateinamen in ZIPs als auch den Anforderungen an die cid-URLs genügen.
MIME-Type
OpenPortfolios verwenden den MIME-Type application/vnd.org.jadice.open-portfolio.
Dieser kann mit dem Versionsparameter version ergänzt werden: application/vnd.org.jadice.open-portfolio;version=1.0
Dateisystem-Erweiterung
Werden OpenPortfolios im ZIP-Container-Format in einem Dateisystem abgelegt, so können sie mit der Endung ".opz" versehen werden.
Beispiel
Die Beispieldatei test.opz enthält ein einfaches OpenPortfolio, das ein Dokument bestehend aus einem JPEG und einem PNG enthält. Zur Illustration sind einige Elemente mit Properties und Metadaten versehen.
Verwandte Artikel