Beyond XML en JDF: die volgende stap

Terwyl XML en JDF die basis vorm vir drukoutomatisering, kom daar nuwe nuwer formate na vore wat die oordrag van data vir drukkers nog doeltreffender kan maak.

In ons reeks waarin die standaarde en lêerformate wat in die outomatiseringsprosesse gebruik word, verduidelik 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 gegroei het óf 'n alternatief vir hierdie formate bied.

Die eerste hiervan is PrintTalk: 'n stelsel wat bestuur word deur die nie-winsgewende organisasie CIP4 (die International Cooperation for the Integration of Processes in Prepress, Press en Postpress). Volgens CIP4 het PrintTalk gegroei uit ''n gemeenskap wat gevorm is deur drukbestuurstelsels en e-handelsondernemings om 'n' beste praktyk 'algemene en oop kommunikasie-koppelvlak te definieer tussen ondernemings wat gedrukte produkte koop, en diegene wat dit vervaardig ".

Prakties, 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 se tegniese hoof, Rainer Prosi (foto hierbo).

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

'Terwyl JDF of XJDF eintlik net produksie -inligting is, het PrintTalk konsepte soos: dit is 'n versoek om 'n kwotasie, of dit is 'n kwotasie, of dit in 'n faktuur, of dit is 'n bestelling.

“PrintTalk bevat saketransaksies, en vir saketransaksies moet u ook beskryf waaroor die transaksie handel, en dit is 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 'n produk skep of bestel. Met PrintTalk kan u die produk wat bestel is, beskryf en ook dinge insluit soos onderhandel oor die prys. Dit kan dan in die poskaartjie geplaas word en na 'n MIS gestuur word om die verwerking van die taak te bepaal.

Gee dit 'n RUS

Maar variasies van JDF of XJDF is nie die enigste opsie vir drukkers, kliënte en vervaardigers nie, veral as dit kom by die stuur van inligting oor die internet. Een van die nadele van JDF - en die katalisator vir die skepping van die meer vaartbelynde XJDF - was dat byna te veel data opgeneem kon word, wat die formaat soms taamlik onhandig maak. Om dit teë te werk, is daar 'n REST -API, of om die volle naam te gee: Programmatuurinterface vir verteenwoordigende staatsoordrag.

XML en JSON kom konseptueel baie ooreen omdat hulle gestruktureerde inhoud het waarmee u sleutelwaardepare kan definieer

In eenvoudiger terme gebruik REST API's die JSON -formaat - wat breedweg gelykstaande is aan XML - om hoogs gespesifiseerde data -oordrag vir spesifieke take tussen versoenbare stelsels te skep, en inligting is maklik oordraagbaar oor http.

'XML en JSON kom konseptueel baie ooreen omdat hulle gestruktureerde inhoud het waarmee u belangrike waardepare kan definieer. Die praktiese voordele van JSON in 'n web-API-omgewing is dat daar baie raamwerke met 'ingeboude' JSON-vermoë is en JSON ook effens meer bondig is. Die voordele van XML is meer volwasse valideringsinstrumente, ”verduidelik Rainer.

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

'U kan dus 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 toewys. Maar dit beteken ook dat as die funksies van die produk verander, die API ook moet verander. En omdat dit spesifiek is, beteken dit wel dat u 'n persoonlike kode vir elke toepassing moet skryf.

Dit is goed om te praat

Alhoewel die spesifisiteit van API's baie doeltreffend is nadat dit eers vir spesifieke doeleindes opgestel en ontwerp is, het dit wel nadele.

'As vervaardigers hul eie API's vir hul produkte het, is dit natuurlik nie gestandaardiseer nie en standaardisering is 'n tweesydige munt. As u standaardiseer, moet u baie algemeen wees, want daar is allerhande gebruiksgevalle wat u moet ondersoek, ”sê Rainer.

Alhoewel API's spesifiek is vir die taak of proses, is die ooreenkoms tussen XML en JSON moontlik dat onderlinge verenigbaarheid tussen formate moontlik is

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

Alhoewel API's spesifiek is vir die taak of proses, is die ooreenkoms tussen XML en JSON moontlik dat onderlinge verenigbaarheid 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 voorbehoude, maar oor die algemeen is dit redelik maklik,' sê Rainer.

'Waaraan CIP4 werk, is 'n een-tot-een-vertaling van XJDF na JSON, sodat u die beste kombinasie van albei moontlike wêrelde kry. U kan REST API's bou, maar dit word dan gestandaardiseer, sodat u nie by dieselfde vervaardiger van toerusting toegesluit kan word nie.

'Natuurlik hou vervaardigers daarvan as hulle hul kliënte kan sluit; kliënte nie. Dan kom die besigheidsbesluite omdat kliënte na hul verkopers moet gaan en sê dat hulle standaarde en meer buigsaamheid wil hê. Die vraag of die vervaardigers dit werklik ondersteun ... wel, dit is die volgende fase in die verhaal! ”