Behalwe XML en JDF: die volgende stap

Terwyl XML en JDF die basis vorm van drukoutomatisering, kom ander nuwer formate na vore wat data-oordrag vir drukkers selfs meer doeltreffend kan maak.

In ons reeks wat die standaarde en lêerformate verduidelik wat in die prosesse van drukoutomatisering gebruik word, het ons gekyk na XML en die meer sektorspesifieke weergawe van XML – JDF en die nuwer XJDF . Daar is egter ander opsies wat óf uit gegroei het óf wat 'n alternatief vir hierdie formate bied.

Die eerste hiervan is PrintTalk: 'n stelsel wat deur nie-winsgewende organisasie CIP4 (die Internasionale Samewerking vir die Integrasie van Prosesse in Prepress, Press and Postpress) bestuur word. Volgens CIP4 het PrintTalk gegroei uit "'n gemeenskap wat gevorm is deur drukbestuurstelsels en e-handelmaatskappye om 'n 'beste praktyk' algemene en oop kommunikasie-koppelvlak te definieer tussen maatskappye wat gedrukte produkte koop, en diegene wat dit vervaardig".

In praktiese terme, deur die gebruik van JDF, XJDF, XML en CXML te ondersteun en uit te brei, kan PrintTalk belangrike finansiële data by die bestuursinligtingstelsel (MIS) voeg.

"PrintTalk is in wese 'n omhulsel rondom JDF of XJDF," verduidelik CIP4 Hoof Tegniese Beampte, Rainer Prosi (foto hierbo).

PrintTalk is die ideale standaard vir iemand wat 'n web-tot-druk-stelsel het wat produk skep of bestel

“Maar terwyl JDF of XJDF eintlik net produksie-inligting is, het PrintTalk konsepte soos dit is 'n versoek vir 'n kwotasie, of dit is 'n kwotasie, of dit in 'n faktuur, of dit is 'n aankoopbestelling.

“PrintTalk inkorporeer saketransaksies en vir saketransaksies moet jy ook beskryf waaroor die transaksie gaan, en dis waar die produkbeskrywings – in hierdie geval van XJDF – ter sprake kom. Dit is die ideale standaard vir iemand wat 'n web-tot-druk-stelsel het wat produk skep of bestel. Met PrintTalk kan jy die produk beskryf wat bestel is en ook dinge insit soos watter prys onderhandel is. Dit kan dan in die poskaartjie geplaas word en na 'n MIS gestuur word om die verwerking van daardie pos te definieer.”

Gee dit 'n RUS

Variasies van JDF of XJDF is egter nie die enigste opsie vir drukkers, kliënte en vervaardigers nie, veral wanneer dit kom by die stuur van inligting oor die web. Een van die nadele van JDF – en die katalisator vir die skepping van die meer vaartbelynde XJDF – was dat byna te veel data ingesluit kon word, wat die formaat soms taamlik moeilik maak. Om dit teë te werk, is daar REST API, of om dit se volle naam te gee: Representational State Transfer Application Programming Interface.

XML en JSON is konseptueel baie soortgelyk deurdat dit gestruktureerde inhoud is wat jou toelaat om sleutelwaardepare te definieer

In eenvoudiger terme gebruik REST API's die JSON-formaat - wat in die breë gelykstaande is aan XML - om hoogs gespesifiseerde data-oordrag vir spesifieke take tussen versoenbare stelsels te skep, met inligting wat maklik oor http oorgedra kan word.

“XML en JSON is konseptueel baie soortgelyk deurdat dit gestruktureerde inhoud is wat jou toelaat om sleutelwaardepare te definieer. Die praktiese voordele van JSON in 'n web API-omgewing is dat daar baie raamwerke is met 'ingeboude' JSON-vermoë en JSON is ook effens meer bondig. Die voordele van XML is meer volwasse valideringsinstrumente,” verduidelik Rainer.

“Dan beteken REST API bloot om JSON oor http te stuur. API's is makliker om te verstaan, want jy kan hulle baie toegewyd maak aan jou sagteware. As jy JDF of XJDF gebruik, dan het jy 'n abstrakte idee van 'n produk of 'n proses, maar as jy 'n API het, kan jy 'n enkele inskrywing maak vir byvoorbeeld elke knoppie op jou gebruikerskoppelvlak of vir elke teksveld.

"So jy kan sê, hierdie teksveld is presies vir hierdie deel van die API. Dit is baie maklik vir iemand wat dit gebruik om te sien hoe dit na die produk gekoppel word. Maar dit beteken ook dat as die kenmerke van die produk verander, die API ook moet verander. En aangesien dit spesifiek is, beteken dit dat jy persoonlike kode vir elke toepassing moet skryf.”

Dis goed om te praat

Alhoewel API's se spesifisiteit hoogs doeltreffend is sodra dit opgestel en vir spesifieke doeleindes ontwerp is, het dit wel sy nadele.

“As vervaardigers hul eie API's vir hul produkte het, is dit natuurlik nie gestandaardiseer nie, en standaardisering is 'n tweesydige muntstuk. As jy standaardiseer, dan moet jy baie algemeen wees, want daar is allerhande gebruiksgevalle waarna jy moet kyk,” sê Rainer.

Alhoewel API's spesifiek vir die werk of proses in die hand is, beteken die ooreenkoms tussen XML en JSON dat interversoenbaarheid tussen formate moontlik is

"Enigiemand wat egter met 'n API wil integreer, doen dit net vir daardie spesifieke situasie en hulle word dan toegesluit. Byvoorbeeld, as 'n drukker van verskaffer van 'n prepress-stelsel wil verander, en die drukker gebruik die REST API van daardie prepress-stelsel, dan moet hulle alles wat hulle gedoen het om hul werkvloei op te stel, weggooi en weer van voor af begin."

Alhoewel API's spesifiek is vir die werk of proses in die hand, beteken die ooreenkoms tussen XML en JSON dat interversoenbaarheid tussen formate moontlik is, en CIP4 werk tans aan 'n vertaalhulpmiddel.

"Dit is redelik eenvoudig om XML na JSON en terug te vertaal - daar is 'n paar waarskuwings, maar oor die algemeen is dit redelik maklik," sê Rainer.

“Waaraan CIP4 werk, is 'n een-tot-een vertaling van XJDF na JSON, sodat jy die beste mengsel van albei moontlike wêrelde kry. Jy kan REST API's bou, maar hulle word dan gestandaardiseer sodat jy nie by dieselfde toerustingvervaardiger toegesluit is nie.

“Natuurlik hou vervaardigers daarvan as hulle hul kliënte kan toesluit; kliënte nie. So dan kom die besigheidsbesluite, want kliënte sal na hul verkopers moet gaan en sê hulle wil standaarde en meer buigsaamheid hê. Die vraag of die vervaardigers dit werklik ondersteun … wel, dit is die volgende fase in die storie!”