Poza XML i JDF: kolejny krok

Podczas gdy XML i JDF stanowią podstawę automatyzacji drukowania, pojawiają się inne nowsze formaty, które mogą sprawić, że transfer danych dla drukarek będzie jeszcze bardziej wydajny.

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

Pierwszym z nich jest PrintTalk: system zarządzany przez organizację non-profit CIP4 (Międzynarodowa Współpraca na rzecz Integracji Procesów w Prepressie, Prasie i Postpressie). Według CIP4, PrintTalk wyrósł ze „społeczności utworzonej przez systemy zarządzania drukiem i firmy zajmujące się handlem elektronicznym w celu zdefiniowania wspólnego i otwartego interfejsu komunikacyjnego „najlepszych praktyk” między firmami, które kupują produkty drukowane, a tymi, którzy je wytwarzają”.

W praktyce, wspierając i rozszerzając wykorzystanie JDF, XJDF, XML i CXML, PrintTalk może dodać istotne dane finansowe do systemu informacji zarządczej (MIS).

„PrintTalk jest zasadniczo opakowaniem wokół JDF lub XJDF”, wyjaśnia dyrektor techniczny CIP4 Rainer Prosi (na zdjęciu powyżej).

PrintTalk to idealny standard dla kogoś, kto ma system web-to-print, który tworzy lub zamawia produkt

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

„PrintTalk obejmuje transakcje biznesowe, a w przypadku transakcji biznesowych musisz również opisać, czego dotyczy transakcja, i tu właśnie wchodzą w grę opisy produktów – w tym przypadku od XJDF. To idealny standard dla kogoś, kto posiada system web-to-print, który tworzy lub zamawia produkt. Za pomocą PrintTalk możesz opisać zamówiony produkt, a także umieścić takie rzeczy jak wynegocjowana cena. Można to następnie umieścić w bilecie pracy i wysłać do systemu MIS w celu zdefiniowania przetwarzania tego zadania”.

Daj spokój

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 Internet. Jedną z wad JDF – i katalizatorem stworzenia bardziej uproszczonego XJDF – było to, że można było włączyć prawie zbyt wiele danych, przez co format czasami był raczej nieporęczny. Aby temu przeciwdziałać, istnieje REST API, lub aby nadać mu pełną nazwę: Representational State Transfer Application Programming Interface.

XML i JSON są koncepcyjnie bardzo podobne, ponieważ są ustrukturyzowaną zawartością, która pozwala zdefiniować pary klucz-wartość

Mówiąc prościej, interfejsy API REST używają formatu JSON – który jest w dużej mierze odpowiednikiem XML – do tworzenia wysoce określonych transferów danych dla określonych zadań między kompatybilnymi systemami, przy czym informacje można łatwo przesyłać przez http.

„XML i JSON są koncepcyjnie bardzo podobne, ponieważ są ustrukturyzowaną zawartością, która pozwala zdefiniować pary klucz-wartość. Praktyczne zalety JSON w środowisku internetowego interfejsu API polegają na tym, że istnieje wiele struktur z „wbudowaną” funkcją JSON, a JSON jest również nieco bardziej zwięzły. Zaletą XML są bardziej dojrzałe narzędzia do walidacji”, wyjaśnia Rainer.

„Wtedy REST API oznacza po prostu wysyłanie JSON przez http. Interfejsy API są łatwiejsze do zrozumienia, ponieważ możesz uczynić je bardzo dedykowanymi dla Twojego oprogramowania. Jeśli używasz JDF lub XJDF, to masz abstrakcyjne pojęcie o produkcie lub procesie, ale jeśli masz API, możesz dokonać pojedynczego wpisu, 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. Ktoś, kto z tego korzysta, może bardzo łatwo zobaczyć, jak to się mapuje do produktu. Ale oznacza to również, że jeśli zmienią się cechy produktu, API również musi się zmienić. A ponieważ jest specyficzny, oznacza to, że musisz napisać niestandardowy kod dla każdej aplikacji”.

Dobrze jest porozmawiać

Chociaż specyfika interfejsów API jest bardzo wydajna po skonfigurowaniu i zaprojektowaniu do określonych celów, ma ona swoje wady.

„Jeśli producenci mają własne API dla swoich produktów, to oczywiście nie jest to ustandaryzowane, a standaryzacja to moneta dwustronna. Jeśli standaryzujesz, musisz być bardzo ogólny, ponieważ istnieją różne rodzaje przypadków użycia, którym musisz się przyjrzeć” – 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 kompatybilność między formatami

„Jednak każdy, kto chce zintegrować się z API, robi to tylko w tej konkretnej sytuacji, a następnie zostaje zablokowany. Na przykład, jeśli drukarz chce zmienić dostawcę systemu prepress, a drukarka korzysta z REST API tego systemu przygotowania do druku, wtedy muszą wyrzucić wszystko, co zrobili, aby skonfigurować swój przepływ pracy i zacząć od nowa”.

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

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

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

„Oczywiście producentom podoba się to, że mogą zablokować swoich klientów; klienci nie. A potem przychodzą 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 kolejny etap w historii!”