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 sobre 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 nuevo XJDF . Sin embargo, existen otras opciones que han surgido de estos formatos o que ofrecen una alternativa a ellos.

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 empresas de sistemas de gestión de impresión y de comercio electrónico para definir una interfaz de comunicación 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 básicamente un envoltorio de JDF o XJDF”, explica el director técnico de CIP4, Rainer Prosi (en la foto de arriba).

PrintTalk es el estándar ideal para alguien que tiene un sistema de impresión web que crea o solicita productos.

“Pero mientras que JDF o XJDF son realmente solo información de producción, PrintTalk tiene conceptos como esto es una solicitud de cotización, o esto es una cotización, o esto en una factura, o esto 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 de productos, en este caso de XJDF. Es el estándar ideal para alguien que tiene un sistema de impresión web que crea o solicita productos. Con PrintTalk, puede describir el producto que se ha pedido y también incluir cosas como el precio que se ha negociado. Luego, eso se puede incluir en la orden de trabajo y enviar 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 del XJDF más simplificado) era que se podían incorporar demasiados datos, lo que hacía que el formato, a veces, fuera bastante difícil de manejar. Para contrarrestar esto, existe la API REST, o por 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 utilizan el formato JSON, que es ampliamente equivalente a XML, para crear una transferencia de datos altamente especificada para trabajos específicos entre sistemas compatibles, donde la información se puede transmitir fácilmente a través de http.

“XML y JSON son conceptualmente muy similares, ya que son contenido estructurado que 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 'integrada' y JSON también es un poco más conciso. Las ventajas de XML son herramientas de validación más maduras”, explica Rainer.

“La API REST simplemente significa enviar JSON a través de http. Las API son más fáciles de entender porque puedes hacerlas muy específicas para tu software. Si usas JDF o XJDF, entonces tienes una idea abstracta de un producto o un proceso pero, si tienes una API, entonces puedes hacer una sola entrada para, por ejemplo, cada botón en tu interfaz de usuario o para cada campo de texto.

“Se puede decir que 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, entonces la API también debe cambiar. Y como es específica, significa que hay que escribir código personalizado para cada aplicación”.

Es bueno hablar

Si bien la especificidad de las API es muy eficiente una vez configuradas y diseñadas para propósitos particulares, también tiene sus desventajas.

"Si los fabricantes tienen sus propias API para sus productos, por supuesto que no están estandarizadas, y la estandarización es una moneda de dos caras. Si se estandariza, entonces hay que ser muy general porque hay todo tipo de casos de uso que hay que tener en cuenta", afirma 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 hace solo para esa situación específica y, por lo tanto, queda atado a ella. Por ejemplo, si un impresor quiere cambiar de proveedor de un sistema de preimpresión y el impresor está utilizando la API REST de ese sistema de preimpresión, entonces tiene que descartar todo lo que ha 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 actualmente en una herramienta de traducción.

“Es bastante sencillo traducir XML a JSON y viceversa; hay algunas salvedades, pero en general es bastante fácil”, afirma Rainer.

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

“Por supuesto, a los fabricantes les gusta poder mantener a sus clientes a raya, pero a los propios 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!”