Poza XML i JDF: kolejny krok

Chociaż XML i JDF stanowią podstawę automatyzacji druku, pojawiają się też nowsze formaty, które mogą sprawić, że przesyłanie danych do drukarek stanie się jeszcze bardziej wydajne.

W naszej serii wyjaśniającej standardy i formaty plików, które są używane w procesach automatyzacji druku, przyjrzeliśmy się XML i bardziej sektorowej wersji XML – JDF i nowszemu XJDF . Istnieją jednak inne opcje, które albo wyrosły z tych formatów, albo oferują alternatywę dla nich.

Pierwszym z nich jest PrintTalk: system zarządzany przez organizację non-profit CIP4 (International Cooperation for the Integration of Processes in Prepress, Press and Postpress). Według CIP4 PrintTalk wyrósł ze „społeczności utworzonej przez systemy zarządzania drukiem i firmy e-commerce w celu zdefiniowania „najlepszych praktyk” wspólnego i otwartego interfejsu komunikacyjnego między firmami, które kupują produkty drukowane, a tymi, które je produkują”.

W praktyce PrintTalk może dodawać istotne dane finansowe do systemu informacji zarządczej (MIS) poprzez obsługę i rozszerzanie zastosowań formatów JDF, XJDF, XML i CXML.

„PrintTalk to w zasadzie opakowanie dla JDF lub XJDF” – wyjaśnia Rainer Prosi, dyrektor techniczny CIP4 (na zdjęciu powyżej).

PrintTalk to idealny standard dla osób, które mają system web-to-print służący do tworzenia lub zamawiania produktów

„Jednak podczas gdy JDF i XJDF to tak naprawdę tylko informacje o produkcji, PrintTalk wykorzystuje takie koncepcje, jak prośba o wycenę, wycena, faktura lub zamówienie zakupu.

„PrintTalk obejmuje transakcje biznesowe, a w przypadku transakcji biznesowych należy również opisać, czego dotyczy transakcja, i tu właśnie wchodzą w grę opisy produktów – w tym przypadku z XJDF. To idealny standard dla kogoś, kto ma system web-to-print, który tworzy lub zamawia produkty. Używając PrintTalk można opisać zamówiony produkt, a także wprowadzić takie informacje, jak wynegocjowana cena. Następnie można to umieścić w bilecie zadania i wysłać do MIS, aby zdefiniować przetwarzanie tego zadania”.

Daj mu ODPOCZYNEK

Jednak odmiany JDF lub XJDF nie są jedyną opcją dla drukarek, klientów i producentów, zwłaszcza jeśli chodzi o przesyłanie informacji przez sieć. Jedną z wad JDF – i katalizatorem dla stworzenia bardziej usprawnionego XJDF – było to, że można było włączyć niemal zbyt wiele danych, przez co format ten czasami był dość nieporęczny. Aby temu przeciwdziałać, istnieje REST API, lub jak brzmi jego pełna nazwa: Representational State Transfer Application Programming Interface.

XML i JSON są bardzo podobne pod względem koncepcyjnym, ponieważ stanowią ustrukturyzowaną treść, która umożliwia definiowanie par klucz-wartość

Mówiąc prościej, interfejsy API REST wykorzystują format JSON – który jest w zasadzie odpowiednikiem XML – w celu tworzenia ściśle określonych transferów danych dla konkretnych zadań między zgodnymi systemami, a informacje można łatwo przesyłać przez protokół http.

„XML i JSON są koncepcyjnie bardzo podobne, ponieważ są to treści strukturalne, które pozwalają definiować pary klucz-wartość. Praktyczne zalety JSON w środowisku API sieci Web polegają na tym, że istnieje wiele struktur z „wbudowaną” możliwością JSON, a JSON jest również nieco bardziej zwięzły. Zaletami XML są bardziej dojrzałe narzędzia walidacyjne”, wyjaśnia Rainer.

„W takim razie REST API oznacza po prostu wysyłanie JSON przez http. API są łatwiejsze do zrozumienia, ponieważ można je uczynić bardzo dedykowanymi dla oprogramowania. Jeśli używasz JDF lub XJDF, masz abstrakcyjny pomysł na produkt lub proces, ale jeśli masz API, możesz utworzyć pojedynczy wpis, na przykład dla każdego przycisku w interfejsie użytkownika lub dla każdego pola tekstowego.

„Można więc powiedzieć, że to pole tekstowe jest przeznaczone właśnie dla tej części API. Bardzo łatwo jest komuś, kto z niego korzysta, zobaczyć, jak mapuje się ono na produkt. Ale oznacza to również, że jeśli funkcje produktu ulegną zmianie, API również musi się zmienić. A ponieważ jest to specyficzne, oznacza to, że trzeba napisać niestandardowy kod dla każdej aplikacji”.

Dobrze jest porozmawiać

Choć specyfika interfejsów API jest niezwykle efektywna po ich skonfigurowaniu i zaprojektowaniu do konkretnych celów, ma też swoje wady.

„Jeśli producenci mają własne API dla swoich produktów, oczywiście nie jest to standaryzowane, a standaryzacja jest dwustronną monetą. Jeśli standaryzujesz, musisz być bardzo ogólny, ponieważ istnieją różne przypadki użycia, które musisz zbadać” – mówi Rainer.

Chociaż interfejsy API są specyficzne dla danego zadania lub procesu, podobieństwo między XML i JSON oznacza, że możliwa jest interkompatybilność między formatami

„Jednak każdy, kto chce zintegrować się z API, robi to tylko w tej konkretnej sytuacji i jest wtedy zablokowany. Na przykład, jeśli drukarnia chce zmienić dostawcę systemu prepress, a drukarnia używa REST API tego systemu prepress, musi wyrzucić wszystko, co zrobiła, aby skonfigurować swój przepływ pracy i zacząć od nowa”.

Choć interfejsy API są specyficzne dla konkretnego zadania lub procesu, podobieństwo między XML i JSON oznacza, że możliwa jest interkompatybilność między formatami. CIP4 pracuje obecnie nad narzędziem do tłumaczenia.

„Tłumaczenie XML na JSON i z powrotem jest stosunkowo proste – jest kilka zastrzeżeń, ale generalnie jest to dość łatwe” – mówi Rainer.

„CIP4 pracuje nad tłumaczeniem XJDF na JSON w trybie jeden do jednego, aby uzyskać najlepszą mieszankę obu możliwych światów. Można budować interfejsy API REST, ale są one następnie standaryzowane, aby nie być ograniczonym do tego samego producenta sprzętu.

„Oczywiście, producenci lubią, gdy mogą przyciągnąć swoich klientów; klienci nie. Wtedy pojawiają się decyzje biznesowe, ponieważ klienci będą musieli udać się do swoich dostawców i powiedzieć, że chcą standardów i większej elastyczności. Pytanie, czy producenci faktycznie to wspierają… cóż, to jest kolejny etap historii!”