Untergeordnete Seiten
  • Spezifikation des OpenPortfolio-Formats
Zum Ende der Metadaten springen
Zum Anfang der Metadaten
Icon

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 gild 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:

OpenPortfolio Datenmodell

FEHLER

Gliffy ist nicht lizenziert. Bitte installieren Sie eine Lizenz, um Diagramme in Ihrem Wiki zu zeichnen.

Die einzelnen Elemente haben folgende Funktion:

ElementFunktion
OpenPortfolioWurzelobjekt eines Portfolios
Pageeine einzelne Seite des zusammengesetzten Dokuments
PageSegmenteine Ebene innerhalb der Seite eines zusammengesetzten Dokuments; verweist auf Seite eines Teildokuments
Streamein Datenstrom, der ein Teildokument transportiert
MetadataMetadaten in XML-Form
PropertiesBenutzerdefinierte 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:

OpenPortfolio-Struktur

FEHLER

Gliffy ist nicht lizenziert. Bitte installieren Sie eine Lizenz, um Diagramme in Ihrem Wiki zu zeichnen.

Die einzelnen Elemente haben folgende Funktion:

ElementFunktion
ContainerDer 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.
ManifestDas 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..nDie 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 ##any definiert.
  • 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
    • Erweiterungen (siehe unten)

Erweiterungs-Schemata

Das Manifest-Schema kann mit Erweiterungsschemata um proprietäre Erweiterungen ergänzt werden. Implementierungen, die eine Erweiterung nicht unterstützen, sollen Elemente aus Erweiterungsschemata ignorieren. Namensräume von verwendeten Erweiterungsschemata müssen im Manifest korrekt deklariert werden.

Das jadice-Erweiterungs-Schema

Das jadice-Erweiterungs-Schema definiert derzeit einen zusätzlichen Datentyp, der als Wert einer Property verwendet werden kann: java-serialized-object.

Werte des Typs java-serialized-object enthalten Daten, die nicht sinnvoll auf einen der vordefinierten Typen abgebildet werden können. Der Inhalt der Elemente ist ein Base-64-kodierter Datenstrom, der ein serialisiertes Java-Objekt enthält.

Darüber hinaus erlaubt es das jadice-Erweiterungs-Schema, Kollektionstypen um die Information, welche Java-Klasse zu ihrer Implementierung verwendet wurde, zu ergänzen.

Beispiel

Beispiel-Manifest

 

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:

DateinameAnzahlInhaltAnmerkungen
OPEN-PORTFOLIO1Versionsnummer 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.
MANIFEST1Das ManifestKann 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:

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