Jenseits von XML und JDF: der nächste Schritt

Während XML und JDF die Basis der Druckautomatisierung bilden, entstehen andere neuere Formate, die den Datentransfer für Drucker noch effizienter machen können.

In unserer Serie zu den Standards und Dateiformaten, die in den Prozessen der Druckautomatisierung verwendet werden, haben wir uns mit XML und der eher branchenspezifischen Version von XML – JDF und dem neueren XJDF – befasst. Es gibt jedoch andere Optionen, die entweder aus diesen Formaten herausgewachsen sind oder eine Alternative zu diesen bieten.

Die erste davon ist PrintTalk: ein System, das von der gemeinnützigen Organisation CIP4 (International Cooperation for the Integration of Processes in Prepress, Press and Postpress) verwaltet wird. Laut CIP4 ist PrintTalk aus „einer Gemeinschaft von Druckmanagementsystemen und E-Commerce-Unternehmen entstanden, um eine gemeinsame und offene Kommunikationsschnittstelle 'Best-Practice' zwischen Unternehmen, die Druckerzeugnisse kaufen, und denen, die sie herstellen, zu definieren“.

In der Praxis kann PrintTalk durch die Unterstützung und Erweiterung der Verwendung von JDF, XJDF, XML und CXML wichtige Finanzdaten zum Management Information System (MIS) hinzufügen.

„PrintTalk ist im Wesentlichen ein Wrapper um JDF oder XJDF“, erklärt Rainer Prosi, Chief Technical Officer von CIP4 (Bild oben).

PrintTalk ist der ideale Standard für jemanden, der über ein Web-to-Print-System verfügt, das Produkte erstellt oder bestellt

„Aber während JDF oder XJDF eigentlich nur Produktionsinformationen sind, hat PrintTalk Konzepte wie diese, eine Angebotsanfrage, ein Angebot, eine Rechnung oder eine Bestellung.

„PrintTalk beinhaltet Geschäftsvorfälle und bei Geschäftsvorfällen muss man auch beschreiben, worum es bei der Transaktion geht, und hier kommen die Produktbeschreibungen – in diesem Fall von XJDF – ins Spiel. Es ist der ideale Standard für jemanden, der über ein Web-to-Print-System verfügt, das Produkte erstellt oder bestellt. Mit PrintTalk können Sie das bestellte Produkt beschreiben und beispielsweise den verhandelten Preis angeben. Das kann dann in das Jobticket eingefügt und an ein MIS gesendet werden, um die Verarbeitung dieses Jobs zu definieren.“

Gib ihm eine RUHE

JDF- oder XJDF-Varianten sind jedoch nicht die einzige Option für Drucker, Kunden und Hersteller, insbesondere wenn es um den Versand von Informationen über das Internet geht. Einer der Nachteile von JDF – und der Auslöser für die Erstellung des schlankeren XJDF – war, dass fast zu viele Daten integriert werden konnten, was das Format manchmal ziemlich unhandlich machte. Um dem entgegenzuwirken, gibt es die REST-API, oder um es mit vollem Namen zu nennen: Representational State Transfer Application Programming Interface.

XML und JSON sind sich konzeptionell sehr ähnlich, da es sich um strukturierte Inhalte handelt, mit denen Sie Schlüssel/Wert-Paare definieren können

Einfacher ausgedrückt, verwenden REST-APIs das JSON-Format – das weitgehend XML entspricht –, um einen hochspezifizierten Datentransfer für bestimmte Jobs zwischen kompatiblen Systemen zu schaffen, wobei Informationen einfach über http übertragen werden können.

„XML und JSON sind sich konzeptionell sehr ähnlich, da es sich um strukturierte Inhalte handelt, die es Ihnen ermöglichen, Schlüssel/Wert-Paare zu definieren. Die praktischen Vorteile von JSON in einer Web-API-Umgebung bestehen darin, dass es viele Frameworks mit „eingebauter“ JSON-Fähigkeit gibt und JSON auch etwas prägnanter ist. Die Vorteile von XML sind ausgereiftere Validierungswerkzeuge“, erklärt Rainer.

„Dann bedeutet REST API einfach das Senden von JSON über http. APIs sind leichter zu verstehen, da Sie sie sehr speziell für Ihre Software einrichten können. Wenn Sie JDF oder XJDF verwenden, haben Sie eine abstrakte Vorstellung von einem Produkt oder einem Prozess, aber wenn Sie eine API haben, können Sie beispielsweise für jede Schaltfläche auf Ihrer Benutzeroberfläche oder für jedes Textfeld einen einzigen Eintrag machen .

„Man kann also sagen, dieses Textfeld ist genau für diesen Teil der API. Es ist sehr einfach für jemanden, der das verwendet, um zu sehen, wie es dem Produkt zugeordnet ist. Es bedeutet aber auch, wenn sich die Funktionen des Produkts ändern, dann muss sich auch die API ändern. Und da es spezifisch ist, müssen Sie für jede Anwendung benutzerdefinierten Code schreiben.“

Es tut gut zu reden

Obwohl die Spezifität von APIs hocheffizient ist, wenn sie einmal eingerichtet und für bestimmte Zwecke entwickelt wurden, hat sie auch ihre Nachteile.

„Wenn Hersteller ihre eigenen APIs für ihre Produkte haben, ist das natürlich nicht standardisiert, und Standardisierung ist eine zweiseitige Medaille. Wenn man standardisiert, muss man sehr allgemein sein, denn es gibt alle möglichen Anwendungsfälle, die man sich anschauen muss“, sagt Rainer.

Obwohl APIs spezifisch für den jeweiligen Job oder Prozess sind, bedeutet die Ähnlichkeit zwischen XML und JSON, dass eine Kompatibilität zwischen den Formaten möglich ist

„Jeder, der eine API integrieren möchte, tut dies jedoch nur für diese spezielle Situation und ist dann gesperrt. Zum Beispiel, wenn ein Drucker den Lieferanten eines Druckvorstufensystems wechseln möchte und der Drucker die REST-API von . verwendet dieses Druckvorstufensystem, dann müssen sie alles, was sie für die Einrichtung ihres Workflows getan haben, wegwerfen und von vorne beginnen.“

Obwohl APIs spezifisch für den jeweiligen Job oder Prozess sind, bedeutet die Ähnlichkeit zwischen XML und JSON, dass die Interkompatibilität zwischen den Formaten möglich ist, und CIP4 arbeitet derzeit an einem Übersetzungstool.

„Es ist ziemlich einfach, XML in JSON und zurück zu übersetzen – es gibt ein paar Vorbehalte, aber im Allgemeinen ist es ziemlich einfach“, sagt Rainer.

„Was CIP4 arbeitet, ist eine Eins-zu-Eins-Übersetzung von XJDF in JSON, damit Sie die beste Mischung aus beiden möglichen Welten erhalten. Sie können REST-APIs erstellen, aber sie werden dann standardisiert, sodass Sie nicht an denselben Gerätehersteller gebunden sind.

„Natürlich mögen es Hersteller, wenn sie ihre Kunden an sich binden können; Kunden nicht. Dann kommen die geschäftlichen Entscheidungen, denn Kunden müssen zu ihren Anbietern gehen und sagen, dass sie Standards und mehr Flexibilität wünschen. Die Frage, ob die Hersteller das tatsächlich unterstützen… na ja, das ist der nächste Schritt in der Geschichte!“