XMLとJDFを超えて: 次のステップ

XML と JDF は印刷自動化の基礎を形成しますが、プリンターのデータ転送をさらに効率的にできる他の新しい形式も登場しています。

印刷自動化のプロセスで使用される標準とファイル形式を説明するシリーズでは、 XMLと、より業界固有の XML バージョンであるJDF と新しい XJDFについて説明しました。ただし、これらの形式から派生したオプションや、これらの形式に代わるオプションもいくつかあります。

その最初のものが PrintTalk です。これは、非営利団体 CIP4 (プリプレス、プレス、ポストプレスのプロセス統合のための国際協力) によって管理されているシステムです。CIP4 によると、PrintTalk は「印刷製品を購入する企業と製造する企業の間で「ベスト プラクティス」の共通かつオープンな通信インターフェイスを定義するために、印刷管理システムと電子商取引企業によって形成されたコミュニティ」から生まれました。

実際には、JDF、XJDF、XML、CXML の使用をサポートおよび拡張することで、PrintTalk は重要な財務データを管理情報システム (MIS) に追加できます。

「PrintTalk は本質的に JDF または XJDF のラッパーです」と CIP4 の最高技術責任者 Rainer Prosi 氏 (上の写真) は説明します。

PrintTalkは、製品を作成または注文するWeb to Printシステムを持つ人にとって理想的な標準です。

「しかし、JDF や XJDF は実際には単なる生産情報ですが、PrintTalk には、これは見積依頼、これは見積、これは請求書、これは注文書などの概念があります。

「PrintTalk にはビジネス トランザクションが組み込まれており、ビジネス トランザクションでは、トランザクションの内容も記述する必要があります。そこで、製品の説明 (この場合は XJDF から) が役立ちます。これは、製品を作成または注文する Web 印刷システムを持つ人にとって理想的な標準です。PrintTalk を使用すると、注文された製品の説明や、交渉された価格などの情報も入力できます。その後、それをジョブ チケットに入れて MIS に送信し、そのジョブの処理を定義できます。」

休んでください

しかし、JDF や XJDF のバリエーションは、特に Web 経由で情報を送信する場合、印刷業者、顧客、製造業者にとって唯一の選択肢ではありません。JDF の欠点の 1 つ (そして、より合理化された XJDF の作成のきっかけとなったもの) は、組み込むことができるデータが多すぎるため、形式が扱いにくくなることがあることです。これに対処するために、REST API があります。正式名称は Representational State Transfer Application Programming Interface です。

XMLとJSONは、キーと値のペアを定義できる構造化されたコンテンツであるという点で概念的に非常に似ています。

簡単に言えば、REST API は JSON 形式 (XML とほぼ同等) を使用して、互換性のあるシステム間で特定のジョブに対して高度に指定されたデータ転送を作成し、情報を http 経由で簡単に転送できるようにします。

「XML と JSON は、キーと値のペアを定義できる構造化されたコンテンツであるという点で、概念的に非常に似ています。Web API 環境における JSON の実際的な利点は、JSON 機能が組み込まれたフレームワークが多数存在し、JSON の方が若干簡潔でもあることです。XML の利点は、より成熟した検証ツールであることです」と Rainer 氏は説明します。

「REST API は、単に JSON を http 経由で送信することを意味します。API はソフトウェア専用にできるため、理解しやすいです。JDF または XJDF を使用する場合は、製品またはプロセスについて抽象的な概念がありますが、API があれば、たとえばユーザー インターフェイスの各ボタンまたは各テキスト フィールドに対して単一のエントリを作成できます。

「つまり、このテキスト フィールドはまさに API のこの部分用だと言えます。これを使用している人にとって、それが製品にどのようにマッピングされるかは非常に簡単です。しかし、製品の機能が変更されると、API も変更する必要があることも意味します。また、API は特定のものであるため、アプリケーションごとにカスタム コードを記述する必要があります。」

話すのはいいことだ

API の特異性は、特定の目的に合わせて設定および設計されると非常に効率的ですが、欠点もあります。

「メーカーが自社製品用に独自の API を持っている場合、それは当然標準化されていません。標準化は二面性があります。標準化する場合は、検討しなければならないさまざまなユースケースがあるため、非常に汎用的である必要があります」と Rainer 氏は言います。

APIはジョブやプロセスに固有のものですが、XMLとJSONの類似性により、フォーマット間の相互互換性が可能です。

「しかし、API との統合を希望する人は、特定の状況のためだけにそれを実行しているため、その状況に縛られてしまいます。たとえば、印刷会社がプリプレス システムのサプライヤーを変更したい場合、その印刷会社がそのプリプレス システムの REST API を使用している場合、ワークフローを設定するために行ったすべての作業を破棄し、最初からやり直す必要があります。」

API は手元のジョブまたはプロセスに固有のものですが、XML と JSON の類似性により、フォーマット間の相互互換性が可能であり、CIP4 は現在、変換ツールの開発に取り組んでいます。

「XML を JSON に変換したり、その逆を行ったりするのはかなり簡単です。いくつか注意点はありますが、一般的にはかなり簡単です」と Rainer 氏は言います。

「CIP4 が取り組んでいるのは、XJDF から JSON への 1 対 1 の変換です。これにより、両方の可能性を最適に組み合わせることができます。REST API を構築できますが、それらは標準化されるため、同じ機器メーカーに縛られることはありません。」

「もちろん、メーカーは顧客を囲い込めればそれを望みますが、顧客はそうではありません。そこでビジネス上の決定が下されます。なぜなら、顧客はベンダーに、標準とさらなる柔軟性を求めなければならないからです。メーカーが実際にこれを支持するかどうかという疑問は、次の段階です！」