Au-delà de XML et JDF : la prochaine étape

Alors que XML et JDF constituent la base de l'automatisation de l'impression, d'autres formats plus récents font leur apparition et peuvent rendre le transfert de données pour les imprimantes encore plus efficace.

Dans notre série expliquant les normes et les formats de fichiers utilisés dans les processus d'automatisation de l'impression, nous avons examiné XML et la version plus spécifique au secteur de XML – JDF et la plus récente XJDF . Cependant, il existe d'autres options qui sont issues de ces formats ou qui offrent une alternative à ces formats.

Le premier d'entre eux est PrintTalk : un système géré par l'asbl CIP4 (la Coopération internationale pour l'intégration des processus en prépresse, presse et postpresse). Selon CIP4, PrintTalk est né d'une « communauté formée de systèmes de gestion d'impression et de sociétés de commerce électronique pour définir une interface de communication commune et ouverte de « bonnes pratiques » entre les entreprises qui achètent des produits imprimés et ceux qui les fabriquent ».

Concrètement, en prenant en charge et en étendant l'utilisation de JDF, XJDF, XML et CXML, PrintTalk peut ajouter des données financières vitales au système d'information de gestion (MIS).

"PrintTalk est essentiellement un wrapper autour de JDF ou XJDF", explique Rainer Prosi, directeur technique de CIP4 (photo ci-dessus).

PrintTalk est la norme idéale pour quelqu'un qui possède un système d'impression Web qui crée ou commande des produits

« Mais alors que JDF ou XJDF ne sont en réalité que des informations de production, PrintTalk a des concepts tels que celui-ci est une demande de devis, ou ceci est un devis, ou cela dans une facture, ou ceci est un bon de commande.

« PrintTalk intègre les transactions commerciales et pour les transactions commerciales, vous devez également décrire en quoi consiste la transaction, et c'est là que les descriptions de produits - dans ce cas de XJDF - entrent en jeu. C'est la norme idéale pour quelqu'un qui a un système Web-to-print qui crée ou commande des produits. En utilisant PrintTalk, vous pouvez décrire le produit qui a été commandé et également indiquer le prix qui a été négocié. Cela peut ensuite être mis dans le ticket de travail et envoyé à un MIS pour définir le traitement de ce travail.

Lui donner un repos

Cependant, les variantes de JDF ou XJDF ne sont pas la seule option pour les imprimeurs, les clients et les fabricants, en particulier lorsqu'il s'agit d'envoyer des informations sur le Web. L'un des inconvénients de JDF - et le catalyseur de la création du XJDF plus rationalisé - était que presque trop de données pouvaient être incorporées, ce qui rendait le format, parfois, assez lourd. Pour contrer cela, il existe une API REST, ou pour lui donner son nom complet : Representational State Transfer Application Programming Interface.

XML et JSON sont conceptuellement très similaires en ce qu'ils sont un contenu structuré qui vous permet de définir des paires clé-valeur

En termes plus simples, les API REST utilisent le format JSON - qui est largement équivalent à XML - pour créer un transfert de données hautement spécifié pour des tâches spécifiques entre des systèmes compatibles, les informations étant facilement transmissibles via http.

« XML et JSON sont conceptuellement très similaires en ce sens qu'il s'agit d'un contenu structuré qui vous permet de définir des paires clé-valeur. Les avantages pratiques de JSON dans un environnement d'API Web sont qu'il existe de nombreux frameworks avec une capacité JSON « intégrée » et que JSON est également légèrement plus concis. Les avantages de XML sont des outils de validation plus matures », explique Rainer.

« Ensuite, l'API REST signifie simplement envoyer du JSON sur http. Les API sont plus faciles à comprendre car vous pouvez les rendre très dédiées à votre logiciel. Si vous utilisez JDF ou XJDF, alors vous avez une idée abstraite d'un produit ou d'un processus mais, si vous avez une API, alors vous pouvez faire une seule entrée pour, par exemple, chaque bouton de votre interface utilisateur ou pour chaque champ de texte .

« Donc, vous pouvez dire que ce champ de texte est précisément pour cette partie de l'API. Il est très facile pour quelqu'un qui l'utilise de voir comment il correspond au produit. Mais cela signifie également que si les fonctionnalités du produit changent, l'API doit également changer. Et comme c'est spécifique, cela signifie que vous devez écrire du code personnalisé pour chaque application.

C'est bien de parler

Si la spécificité des API est très efficace une fois configurée et conçue à des fins particulières, elle a ses inconvénients.

« Si les fabricants ont leurs propres API pour leurs produits, bien sûr, ce n'est pas standardisé, et la standardisation est une pièce à double face. Si vous standardisez, vous devez être très général car il y a toutes sortes de cas d'utilisation que vous devez examiner », explique Rainer.

Bien que les API soient spécifiques au travail ou au processus en cours, la similitude entre XML et JSON signifie que l'intercompatibilité entre les formats est possible

"Cependant, quiconque souhaite s'intégrer à une API le fait uniquement pour cette situation spécifique et est alors bloqué. Par exemple, si un imprimeur souhaite changer de fournisseur d'un système de prépresse et que l'imprimeur utilise l'API REST de ce système de prépresse, alors ils doivent jeter tout ce qu'ils ont fait pour configurer leur flux de travail et recommencer à zéro.

Bien que les API soient spécifiques au travail ou au processus en cours, la similitude entre XML et JSON signifie que l'intercompatibilité entre les formats est possible, et CIP4 travaille actuellement sur un outil de traduction.

« Il est assez simple de traduire XML en JSON et inversement – il y a quelques mises en garde, mais en général, c'est assez facile », explique Rainer.

«Ce sur quoi CIP4 travaille, c'est une traduction un à un de XJDF en JSON, afin que vous obteniez le meilleur mélange des deux mondes possibles. Vous pouvez construire des API REST mais elles sont ensuite standardisées afin que vous ne soyez pas enfermé dans le même fabricant d'équipement.

« Bien sûr, les fabricants aiment s'ils peuvent verrouiller leurs clients ; les clients ne le font pas. Viennent ensuite les décisions commerciales, car les clients devront s'adresser à leurs fournisseurs et leur dire qu'ils veulent des normes et plus de flexibilité. La question de savoir si les fabricants soutiennent réellement cela… eh bien, c'est la prochaine étape de l'histoire !