Bortom XML och JDF: nästa steg

Medan XML och JDF utgör grunden för utskriftsautomatisering, dyker det upp andra nyare format som kan göra dataöverföringen för skrivare ännu mer effektiv.

I vår serie som förklarar de standarder och filformat som används i processerna för utskriftsautomatisering, har vi tittat på XML och den mer sektorspecifika 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.

Det första av dessa är PrintTalk: ett system som hanteras 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 utskriftshanteringssystem och e-handelsföretag för att definiera ett "best practice" gemensamt och öppet kommunikationsgränssnitt mellan företag som köper tryckta produkter och de som tillverkar dem.

Rent praktiskt, genom att stödja och utöka användningen av JDF, XJDF, XML och CXML, kan PrintTalk lägga till viktig ekonomisk data till ledningsinformationssystemet (MIS).

"PrintTalk är i grunden ett omslag runt JDF eller XJDF," förklarar CIP4:s tekniska chef Rainer Prosi (bilden ovan).

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

"Men medan JDF eller XJDF egentligen bara är produktionsinformation, har PrintTalk koncept som att det här är en offertförfrågan, eller det här är en offert, eller det här i en faktura, eller det här är en inköpsorder.

”PrintTalk innehåller affärstransaktioner och för affärstransaktioner behöver du också beskriva vad transaktionen handlar om, och det är där produktbeskrivningarna – i det här fallet från XJDF – kommer in i bilden. Det är den idealiska standarden för någon som har ett webb-till-tryck-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 jobbkortet och skickas till en MIS för att definiera bearbetningen av det jobbet.”

Ge det en VILA

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

XML och JSON är begreppsmässigt mycket lika genom att de är strukturerat innehåll som låter dig definiera nyckelvärdepar

I enklare termer använder REST API:er JSON-formatet – som i stort sett motsvarar 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 över http.

"XML och JSON är begreppsmässigt mycket lika genom att de är strukturerat innehåll som låter dig definiera nyckelvärdespar. De praktiska fördelarna med JSON i en webb-API-miljö är att det finns många ramverk med 'inbyggd' JSON-kapacitet och JSON är också något mer kortfattad. Fördelarna med XML är mer mogna valideringsverktyg”, förklarar Rainer.

"Då innebär 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 inmatning för till exempel varje knapp i ditt användargränssnitt eller för varje textfält.

"Så du kan säga, det här textfältet är just för den här delen av API:et. Det är väldigt lätt för någon som använder det att se hur det mappas till produkten. Men det betyder också att om egenskaperna hos produkten ändras, måste API:et 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:s specificitet är mycket effektiv när den väl har ställts in och designats för särskilda ändamål, har den sina nackdelar.

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

Även om API:er är specifika för jobbet eller processen i hand, betyder likheten mellan XML och JSON interkompatibilitet 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. Till exempel, om en skrivare vill byta leverantör av ett prepress-system och skrivaren använder REST API för det prepress-systemet, då måste de kasta bort 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, betyder likheten mellan XML och JSON interkompatibilitet 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.

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

”Naturligtvis gillar tillverkare om de kan låsa in sina kunder; kunderna 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 verkligen stöder detta... ja, det är nästa steg i historien!”