Utöver XML och JDF: nästa steg

Medan XML och JDF utgör grunden för utskriftsautomatisering, växer andra nya format fram som kan göra dataöverföring för skrivare ännu mer effektiv.

I vår serie som förklarar standarder och filformat som används i processerna för utskriftsautomatisering har vi tittat på XML och den mer sektorsspecifika versionen av XML- JDF och den nyare XJDF . Det finns dock andra alternativ som antingen har vuxit ur eller som erbjuder ett alternativ till dessa format.

Den första av dessa är PrintTalk: ett system som förvaltas av den ideella organisationen CIP4 (International Cooperation for the Integration of Processes in Prepress, Press and Postpress). Enligt CIP4 växte PrintTalk ur ”en gemenskap som bildades av tryckhanteringssystem och e-handelsföretag för att definiera ett” bästa praxis ”gemensamt och öppet kommunikationsgränssnitt mellan företag som köper tryckta produkter och de som tillverkar dem”.

Praktiskt sett, genom att stödja och utöka användningen av JDF, XJDF, XML och CXML, kan PrintTalk lägga till viktiga finansiella data till ledningsinformationssystemet (MIS).

"PrintTalk är i huvudsak ett omslag kring JDF eller XJDF", förklarar CIP4 Chief Technical Officer Rainer Prosi (bilden ovan).

PrintTalk är den perfekta standarden för någon som har ett webb-till-utskriftssystem som skapar eller beställer produkter

”Men medan JDF eller XJDF egentligen bara är produktionsinformation, har PrintTalk begrepp som att detta är en begäran om en offert, eller det här är en offert, eller detta i en faktura, eller detta är en inköpsorder.

“PrintTalk innehåller affärstransaktioner och för affärstransaktioner måste du också beskriva vad transaktionen handlar om, och det är där produktbeskrivningarna - i det här fallet från XJDF - spelar in. Det är den perfekta standarden för någon som har ett web-to-print-system som skapar eller beställer produkter. Med PrintTalk kan du beskriva produkten som har beställts och även lägga in saker som vilket pris som har förhandlats fram. Det kan sedan läggas i jobbbiljetten och skickas till en MIS för att definiera bearbetningen av det jobbet. ”

Lägg av

Men variationer av JDF eller XJDF är inte det enda alternativet för skrivare, kunder och tillverkare, särskilt när det gäller att skicka information över webben. En av baksidorna med JDF - och katalysatorn för skapandet av den mer strömlinjeformade XJDF - var att nästan för mycket data kunde införlivas, vilket gör formatet ibland ganska otympligt. För att motverka detta finns det REST API, eller för att ge det fullständiga namnet: Representational State Transfer Application Programming Interface.

XML och JSON är konceptuellt mycket lika genom att de är strukturerat innehåll som låter dig definiera viktiga värdepar

I enklare termer använder REST API: er JSON -formatet - som i stort sett är ekvivalent med XML - för att skapa mycket specificerad dataöverföring för specifika jobb mellan kompatibla system, med information som lätt kan överföras via http.

“XML och JSON är begreppsmässigt väldigt lika eftersom de är strukturerat innehåll som låter dig definiera viktiga värdepar. De praktiska fördelarna med JSON i en webb-API-miljö är att det finns många ramar med "inbyggd" JSON-kapacitet och JSON är också något mer kortfattad. Fördelarna med XML är mer mogna valideringsverktyg, förklarar Rainer.

”Då betyder REST API helt enkelt att skicka JSON över http. API: er är lättare att förstå eftersom du kan göra dem mycket dedikerade till din programvara. Om du använder JDF eller XJDF har du en abstrakt idé om en produkt eller en process, men om du har ett API kan du göra en enda post för till exempel varje knapp i ditt användargränssnitt eller för varje textfält .

”Så du kan säga att det här textfältet är just för denna del av API: et. Det är väldigt lätt för någon som använder det att se hur det kartlägger produkten. Men det betyder också att om produktens funktioner ändras måste API: n också ändras. Och eftersom det är specifikt betyder det att du måste skriva anpassad kod för varje applikation. ”

Det är bra att prata

Även om API: ernas specificitet är mycket effektiv när den väl är konfigurerad och utformad för särskilda ändamål, har den sina nackdelar.

”Om tillverkare har sina egna API: er för sina produkter, är det naturligtvis inte standardiserat, och standardisering är ett dubbelsidigt mynt. Om du standardiserar dig måste du vara väldigt generell eftersom det finns alla slags användningsfall som du måste titta på, säger Rainer.

Även om API: er är specifika för jobbet eller processen i hand, innebär likheten mellan XML och JSON att kompatibilitet mellan format är möjlig

"Men alla som vill integrera med ett API gör det bara för den specifika situationen och de låses sedan in. Om en skrivare till exempel vill byta leverantör till ett prepress -system och skrivaren använder REST API för det prepress -systemet, då måste de slänga allt de har gjort för att ställa in sitt arbetsflöde och börja om från början. ”

Även om API: er är specifika för jobbet eller processen i hand, innebär likheten mellan XML och JSON att kompatibilitet mellan format är möjlig och CIP4 arbetar med ett översättningsverktyg just nu.

"Det är ganska enkelt att översätta XML till JSON och tillbaka - det finns några varningar men i allmänhet är det ganska enkelt", säger Rainer.

”Det CIP4 arbetar med är en en-till-en-översättning av XJDF till JSON, så att du får den bästa blandningen av båda möjliga världar. Du kan bygga REST -API: er men de standardiseras sedan så att du inte är låst till samma utrustningstillverkare.

”Naturligtvis gillar tillverkare det om de kan låsa in sina kunder; kunder gör det inte. Så då kommer affärsbesluten eftersom kunderna måste gå till sina leverantörer och säga att de vill ha standarder och mer flexibilitet. Frågan om tillverkarna faktiskt stöder detta ... ja, det är nästa steg i historien! ”