Más allá de XML y JDF: el siguiente paso

Si bien XML y JDF forman la base de la automatización de la impresión, están surgiendo otros formatos más nuevos que pueden hacer que la transferencia de datos para las impresoras sea aún más eficiente.

En nuestra serie que explica los estándares y formatos de archivo que se utilizan en los procesos de automatización de la impresión, hemos analizado XML y la versión más específica del sector de XML: JDF y el XJDF más reciente . Sin embargo, existen otras opciones que han surgido o que ofrecen una alternativa a estos formatos.

El primero de ellos es PrintTalk: un sistema gestionado por la organización sin ánimo de lucro CIP4 (Cooperación Internacional para la Integración de Procesos en Preimpresión, Prensa y Postimpresión). Según CIP4, PrintTalk surgió de “una comunidad formada por sistemas de gestión de impresión y empresas de comercio electrónico para definir una interfaz de comunicaciones común y abierta de 'mejores prácticas' entre las empresas que compran productos impresos y las que los fabrican”.

En términos prácticos, al admitir y ampliar el uso de JDF, XJDF, XML y CXML, PrintTalk puede agregar datos financieros vitales al sistema de información de gestión (MIS).

“PrintTalk es esencialmente un envoltorio de JDF o XJDF”, explica el director técnico de CIP4, Rainer Prosi (en la imagen de arriba).

PrintTalk es el estándar ideal para alguien que tiene un sistema de impresión desde la web que crea u ordena productos

“Pero mientras que JDF o XJDF es realmente solo información de producción, PrintTalk tiene conceptos como esta es una solicitud de cotización, o esta es una cotización, o esto en una factura, o esta es una orden de compra.

“PrintTalk incorpora transacciones comerciales y, para las transacciones comerciales, también es necesario describir de qué se trata la transacción, y ahí es donde entran en juego las descripciones del producto, en este caso de XJDF. Es el estándar ideal para alguien que tiene un sistema de impresión desde la web que crea u ordena productos. Con PrintTalk puede describir el producto que se ha pedido y también incluir cosas como el precio que se ha negociado. Eso se puede poner en el ticket de trabajo y enviarlo a un MIS para definir el procesamiento de ese trabajo ".

Dale un descanso

Sin embargo, las variaciones de JDF o XJDF no son la única opción para los impresores, clientes y fabricantes, especialmente cuando se trata de enviar información a través de la web. Una de las desventajas de JDF, y el catalizador para la creación de XJDF más optimizado, fue que se podían incorporar casi demasiados datos, lo que hacía que el formato, a veces, fuera bastante difícil de manejar. Para contrarrestar esto, existe una API REST, o para dar su nombre completo: Interfaz de programación de aplicaciones de transferencia de estado representacional.

XML y JSON son conceptualmente muy similares en el sentido de que son contenido estructurado que le permite definir pares clave-valor.

En términos más simples, las API REST usan el formato JSON, que es en general equivalente a XML, para crear transferencias de datos altamente especificadas para trabajos específicos entre sistemas compatibles, con información que se puede transmitir fácilmente a través de http.

“XML y JSON son conceptualmente muy similares en el sentido de que son contenido estructurado que le permite definir pares clave-valor. Las ventajas prácticas de JSON en un entorno de API web es que hay muchos marcos con capacidad JSON 'incorporada' y JSON también es un poco más conciso. Las ventajas de XML son herramientas de validación más maduras ”, explica Rainer.

“Entonces la API REST simplemente significa enviar JSON a través de http. Las API son más fáciles de entender porque puede hacer que estén muy dedicadas a su software. Si usa JDF o XJDF, entonces tiene una idea abstracta de un producto o proceso pero, si tiene una API, entonces puede hacer una sola entrada para, por ejemplo, cada botón en su interfaz de usuario o para cada campo de texto. .

“Así que puede decir, este campo de texto es precisamente para esta parte de la API. Es muy fácil para alguien que lo use ver cómo se relaciona con el producto. Pero también significa que si las características del producto cambian, la API también tiene que cambiar. Y como es específico, significa que debe escribir código personalizado para cada aplicación ".

Es bueno hablar

Si bien la especificidad de las API es altamente eficiente una vez configuradas y diseñadas para propósitos particulares, tiene sus inconvenientes.

“Si los fabricantes tienen sus propias API para sus productos, por supuesto que no está estandarizado, y la estandarización es una moneda de dos caras. Si estandariza, entonces tiene que ser muy general porque hay todo tipo de casos de uso que debe investigar ”, dice Rainer.

Aunque las API son específicas del trabajo o proceso en cuestión, la similitud entre XML y JSON significa que es posible la intercompatibilidad entre formatos

“Sin embargo, cualquiera que quiera integrarse con una API lo está haciendo solo para esa situación específica y luego está bloqueado. Por ejemplo, si una impresora desea cambiar de proveedor de un sistema de preimpresión y la impresora está utilizando la API REST de ese sistema de preimpresión, luego tienen que deshacerse de todo lo que han hecho para configurar su flujo de trabajo y comenzar de nuevo desde cero ".

Aunque las API son específicas del trabajo o proceso en cuestión, la similitud entre XML y JSON significa que es posible la intercompatibilidad entre formatos, y CIP4 está trabajando en una herramienta de traducción en este momento.

“Es bastante simple traducir XML a JSON y viceversa; hay algunas advertencias, pero en general es bastante fácil”, dice Rainer.

“En lo que CIP4 está trabajando es en una traducción uno a uno de XJDF a JSON, para que obtenga la mejor combinación de ambos mundos posibles. Puede crear API REST, pero luego se estandarizan para que no esté encerrado en el mismo fabricante de equipos.

“Por supuesto, a los fabricantes les gusta si pueden atraer a sus clientes; los clientes no. Entonces vienen las decisiones comerciales porque los clientes tendrán que acudir a sus proveedores y decirles que quieren estándares y más flexibilidad. La cuestión de si los fabricantes realmente apoyan esto ... bueno, ¡esa es la siguiente etapa de la historia! "