الخلاصة

  • يسجّل RFC 9512 النوع application/yaml واللاحقة +yaml لتعريف تسلسلات YAML في التبادل وتفاوض المحتوى.
  • تعريف الصيغة لا يثبت أن الدفق كله قُبل، أو أن معناه صحيح، أو أن أثراً تشغيلياً قد أُذن به.

في الأنظمة المؤتمتة، يسهل أن يتحول الاسم إلى حكم. تصل رسالة ممهورة بـ Content-Type: application/yaml، فيتعرف البرنامج إلى الطريق الأول للمعالجة، ثم تُروى هذه المعرفة وكأنها ثقة كاملة. لكن الاسم لا يقول إلا شيئاً أضيق: المرسل يقدّم التمثيل على أنه YAML. وما بعد ذلك — حدود المحلّل، واكتمال الدفق، وصحة البيانات في سياقها، ومن يجيز الفعل — يبقى قراراً عند الطرف الذي سيتحمل النتيجة.

هذه الدقة هي ما يوفره RFC 9512. فهو يضع اسماً مشتركاً لتمثيلات YAML، ويتيح للأنظمة المستقلة أن تتبادلها أو تتفاوض عليها من دون التباس في نوع الوسيط. ولا يحوّل هذا التسجيل إلى شهادة أمان ولا إلى تفويض من المرسل للمستقبل. إن معرفة صنف الوثيقة ليست معرفة بأن مضمونها ملائم لهذا التطبيق أو لهذه اللحظة.

تظهر الحدود في مسألة النسخة. التسجيل مستقل عن النسخ؛ ويمكن لوثيقة YAML أن تشير إلى نسختها بتوجيه YAML، لكن نوع الوسيط لا يختار ما ستقبله الخدمة. وعلى المستقبل أن يقرر بنفسه أي النسخ والخصائص يقبل. وكذلك، فإن نوعاً متخصصاً ينتهي بـ +yaml يدل على أنه يعتمد تمثيل YAML، لكنه ملزم بتعريف دلالة معرّفات الأجزاء الخاصة به. الاسم العائلي لا يكتب العقد الخاص.

والدفق يفرض سؤالاً أكثر صراحة: ما الذي فُحص بالفعل؟ قد يضم دفق YAML صفراً أو أكثر من الوثائق. ويقول RFC 9512 إن التطبيق الذي يتوقع وثيقة واحدة ينبغي أن يبلغ عن خطأ إذا استلم أكثر من واحدة، بدلاً من إهمال الباقي بصمت. لا يعني ذلك أن تعدد الوثائق خطأ دائماً. بل يعني أن التطبيق لا يملك أن يدّعي فحص مدخل كامل إذا اختار جزءاً منه وبدأ الأثر قبل أن يحسم الباقي.

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

وتصبح المسألة أدق عند الحديث عن الدليل. فإعادة ترميز YAML قد تغيّر الفراغات أو المراسي بما يؤثر في التحقق من التوقيع. والتحويل إلى JSON قد يفقد التعليقات أو التوجيهات أو عقد الأسماء المستعارة، كما أن الدفقات المتعددة والمفاتيح غير النصية والدورات والقيم .inf و.nan والوسوم قد تعقّد التشغيل البيني. لذلك لا يكفي القول إن الناتج «يشبه» الأصل. يجب فصل البايتات المستلمة، والبنية المفسرة، ونتيجة التحقق، وما أذن به صاحب القرار، وما لوحظ بعد التنفيذ.

السلسلة السليمة لا تضع كل هذه المعاني داخل رأس واحد. تُعرّف التمثيل أولاً. ثم تختار إعداد التحليل المقبول وتتحقق من كامل الدفق. ثم تختبر المخطط والمعنى المحلي. وبعد ذلك فقط تقرر سلطة منفصلة إن كان للأمر أثر مسموح. وأخيراً يُسجّل الأثر المرصود. يمكن أن تكون الخطوات آلية، لكن لا يجوز أن تتخفى خطوة داخل اسم الخطوة التي قبلها.

وهذه ليست بيروقراطية زائدة. فمبدأ Heng Lu عن الحد الأدنى من المواصفة المشتركة والقرار اللاحق المحلي يترك للمواصفة ما تستطيع إثباته: هنا هوية التمثيل. أما القرار الذي يغيّر بيئة أو يتحمل خسارة فيجب أن يبقى ظاهراً عند من يتحمله. نجاح الشفرة في تحليل رسالة دليل على قدرة معالجة، وليس دليلاً على تفويض أو نتيجة واقعة.

المصادر