ما بعد XML وJDF: الخطوة التالية

في حين أن XML وJDF يشكلان أساس أتمتة الطباعة، فقد ظهرت تنسيقات أخرى أحدث يمكنها أن تجعل نقل البيانات للطابعات أكثر كفاءة.

في سلسلتنا التي تشرح المعايير وتنسيقات الملفات المستخدمة في عمليات أتمتة الطباعة، نظرنا إلى XML والإصدار الأكثر تخصصًا من XML - JDF والإصدار الأحدث XJDF . ومع ذلك، هناك خيارات أخرى نمت أو تقدم بديلاً لهذه التنسيقات.

إن أول هذه الأنظمة هو PrintTalk: وهو نظام تديره منظمة غير ربحية تدعى CIP4 (التعاون الدولي لدمج العمليات في مرحلة ما قبل الطباعة والطباعة وما بعد الطباعة). ووفقاً لمنظمة CIP4، فقد نشأ نظام PrintTalk من "مجتمع تشكل من أنظمة إدارة الطباعة وشركات التجارة الإلكترونية لتحديد واجهة اتصال مفتوحة ومشتركة "لأفضل الممارسات" بين الشركات التي تشتري المنتجات المطبوعة، وتلك التي تصنعها".

من الناحية العملية، من خلال دعم وتوسيع استخدام JDF وXJDF وXML وCXML، يمكن لـ PrintTalk إضافة بيانات مالية حيوية إلى نظام المعلومات الإدارية (MIS).

يوضح راينر بروسي، كبير مسؤولي التقنية في CIP4 (في الصورة أعلاه): "PrintTalk هو في الأساس غلاف حول JDF أو XJDF".

PrintTalk هو المعيار المثالي لأي شخص لديه نظام طباعة من الويب لإنشاء أو طلب المنتجات

"ولكن في حين أن JDF أو XJDF هي في الحقيقة مجرد معلومات إنتاجية، فإن PrintTalk لديها مفاهيم مثل هذا طلب للحصول على عرض أسعار، أو هذا عرض أسعار، أو هذا في فاتورة، أو هذا أمر شراء.

"يتضمن برنامج PrintTalk المعاملات التجارية، وبالنسبة للمعاملات التجارية، تحتاج أيضًا إلى وصف ما تدور حوله المعاملة، وهنا يأتي دور أوصاف المنتج - في هذه الحالة من XJDF. إنه المعيار المثالي لأي شخص لديه نظام طباعة عبر الويب لإنشاء أو طلب منتج. باستخدام برنامج PrintTalk، يمكنك وصف المنتج الذي تم طلبه وأيضًا وضع أشياء مثل السعر الذي تم التفاوض عليه. يمكن بعد ذلك وضع ذلك في بطاقة المهمة وإرسالها إلى نظام معلومات الإدارة لتحديد معالجة هذه المهمة."

أعطها قسطا من الراحة

ومع ذلك، فإن الاختلافات في JDF أو XJDF ليست الخيار الوحيد للطابعات والعملاء والمصنعين، وخاصة عندما يتعلق الأمر بإرسال المعلومات عبر الويب. كان أحد الجوانب السلبية لـ JDF - والمحفز لإنشاء XJDF الأكثر انسيابية - هو أنه يمكن دمج الكثير من البيانات تقريبًا، مما يجعل التنسيق، في بعض الأحيان، غير قابل للإدارة إلى حد ما. لمواجهة هذا، هناك واجهة برمجة تطبيقات REST، أو لإعطائها اسمها الكامل: واجهة برمجة تطبيقات نقل الحالة التمثيلية.

XML وJSON متشابهان جدًا من الناحية المفاهيمية من حيث أنهما عبارة عن محتوى منظم يسمح لك بتحديد أزواج القيمة الرئيسية

بعبارات أبسط، تستخدم واجهات برمجة التطبيقات REST تنسيق JSON - وهو مكافئ على نطاق واسع لـ XML - لإنشاء نقل بيانات محدد للغاية لوظائف محددة بين أنظمة متوافقة، مع إمكانية نقل المعلومات بسهولة عبر http.

"يتشابه XML وJSON من الناحية المفاهيمية إلى حد كبير من حيث أنهما عبارة عن محتوى منظم يسمح لك بتحديد أزواج القيم الأساسية. تتمثل المزايا العملية لـ JSON في بيئة واجهة برمجة تطبيقات الويب في وجود العديد من الأطر ذات القدرة "المضمنة" على استخدام JSON كما أن JSON أكثر إيجازًا بعض الشيء. تتمثل مزايا XML في أنها أدوات تحقق أكثر نضجًا،" كما يوضح راينر.

"ثم تعني واجهة برمجة التطبيقات REST ببساطة إرسال JSON عبر http. تعد واجهات برمجة التطبيقات أسهل في الفهم لأنك تستطيع جعلها مخصصة جدًا لبرمجياتك. إذا كنت تستخدم JDF أو XJDF، فستكون لديك فكرة مجردة عن منتج أو عملية، ولكن إذا كان لديك واجهة برمجة تطبيقات، فيمكنك إنشاء إدخال واحد، على سبيل المثال، لكل زر في واجهة المستخدم الخاصة بك أو لكل حقل نصي.

"لذا، يمكنك القول إن حقل النص هذا مخصص لهذا الجزء من واجهة برمجة التطبيقات. ومن السهل جدًا على أي شخص يستخدم هذا الحقل أن يرى كيف يتم ربطه بالمنتج. ولكن هذا يعني أيضًا أنه إذا تغيرت ميزات المنتج، فيجب أن تتغير واجهة برمجة التطبيقات أيضًا. وبما أنه محدد، فهذا يعني أنه يتعين عليك كتابة كود مخصص لكل تطبيق."

من الجيد التحدث

على الرغم من أن خصوصية واجهات برمجة التطبيقات (APIs) فعالة للغاية بمجرد إعدادها وتصميمها لأغراض معينة، إلا أنها لها عيوبها.

يقول راينر: "إذا كان لدى الشركات المصنعة واجهات برمجة تطبيقات خاصة بها لمنتجاتها، فمن المؤكد أن هذا ليس معياريًا، والتوحيد القياسي هو عملة ذات وجهين. إذا كنت تقوم بالتوحيد القياسي، فيجب أن تكون عامًا جدًا لأن هناك جميع أنواع حالات الاستخدام التي يجب عليك النظر فيها".

على الرغم من أن واجهات برمجة التطبيقات خاصة بالمهمة أو العملية المطلوبة، فإن التشابه بين XML وJSON يعني إمكانية التوافق بين التنسيقات

"ومع ذلك، فإن أي شخص يريد التكامل مع واجهة برمجة التطبيقات يفعل ذلك فقط لهذا الموقف المحدد، ومن ثم يتم تقييده. على سبيل المثال، إذا أرادت الطابعة تغيير مورد نظام ما قبل الطباعة، وكانت الطابعة تستخدم واجهة برمجة التطبيقات REST لنظام ما قبل الطباعة هذا، فعليها التخلص من كل ما فعلته لإعداد سير عملها والبدء من جديد من الصفر."

على الرغم من أن واجهات برمجة التطبيقات خاصة بالمهمة أو العملية المطلوبة، فإن التشابه بين XML وJSON يعني أن التوافق بين التنسيقات ممكن، وتعمل CIP4 على أداة ترجمة في الوقت الحالي.

يقول راينر: "إن ترجمة XML إلى JSON والعكس أمر بسيط إلى حد ما - هناك بعض التحذيرات ولكن بشكل عام يكون الأمر سهلاً إلى حد ما".

"إن ما يعمل عليه CIP4 هو ترجمة XJDF إلى JSON بشكل فردي، بحيث تحصل على أفضل مزيج من العالمين المحتملين. يمكنك إنشاء واجهات برمجة تطبيقات REST ولكن يتم توحيدها بعد ذلك بحيث لا يتم تقييدك بنفس الشركة المصنعة للمعدات.

"من المؤكد أن الشركات المصنعة تحب أن تتمكن من تأمين عملائها؛ ولكن العملاء لا يحبون ذلك. ثم تأتي القرارات التجارية لأن العملاء سوف يضطرون إلى الذهاب إلى البائعين وإخبارهم بأنهم يريدون معايير ومرونة أكبر. أما السؤال حول ما إذا كانت الشركات المصنعة تدعم هذا بالفعل... حسنًا، هذه هي المرحلة التالية في القصة!"