الملف الفارغ ليس إعفاءً من فحص النموذج المكتمل

الخلاصة

• يتيح RFC 9682 قبول ملف CDDL لا يتضمن قواعد من الناحية النحوية، مع بقاء شرط وجود قاعدة دخول بعد معالجة جميع توجيهات الوحدات.
• لا يكفي إثبات سلامة الملف الأول لإثبات سلامة النموذج المركب. يجب تحديد التبعيات التي استُخدمت، والجذر المختار، والبيئة التي أنتجت النتيجة.

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

هذا النوع من الامتثال لا يرفع جودة النموذج بالضرورة. فهو ينقل جهد الفريق من توضيح النتيجة المطلوبة إلى إرضاء اختبار يجرى قبل اكتمال مدخلاته. لكن حذف الاختبار بلا بديل في المكان المناسب يخلق مشكلة معاكسة: ربما لا يتحقق أحد من النتيجة النهائية.

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

ما الذي يسمح به الصفر؟

في ترميز ABNF المستخدم لكتابة القواعد النحوية، يمكن تحديد الحد الأدنى لتكرار عنصر. إذا كان واحداً فلا بد من ظهور العنصر مرة على الأقل؛ وإذا حُذف الحد الأدنى جاز ألا يظهر. هذه قاعدة لقبول النص نحوياً، وليست قراراً بأن العمل اكتمل. RFC 5234، القسم 3.6

يجيز RFC 9682، المنشور في نوفمبر 2024، ألا يتضمن ملف CDDL أي قاعدة، لأن توجيهات الوحدات قد توفر القواعد كلها. ويبقي القسم 3.1 وجود قاعدة تمنح النموذج نقطة دخول شرطاً دلالياً بعد معالجة جميع التوجيهات. ويستخدم الملحق التوضيحي B.2 أيضاً معالجة لاحقة لمحتوى سلاسل البايتات ذات المحددات، بعد تحليل بنيتها الخارجية. فصل المراحل لا يجعل المحتوى النهائي بلا قيود. RFC 9682

لا يدور النقاش هنا حول بيانات صحيحة الشكل لكنها غير صادقة. السؤال أسبق: هل تكوّن نموذج قابل للاستخدام أصلاً؟ الملف المصدر الفارغ في CDDL ليس نموذجاً نهائياً يقبل كل البيانات بلا تمييز.

في CDDL الأساسي، تكون أول قاعدة معرّفة هي الجذر، ويجب أن تعرّف نوعاً لا مجموعة. وليس مطلوباً أن يكون اسمها الحرفي start. أما مدى تطبيق وصف البيانات داخل البرنامج فهو قرار منفصل لمصممي التطبيق. لا يجوز استخدام هذه المساحة من الاختيار لإلغاء شرط تكوين النموذج. RFC 8610، الأقسام 2.2.4 و4.2 و5

لذلك لا تنتهي المراجعة عند العثور على قاعدة ما. هل هذه هي قاعدة الدخول المقصودة؟ هل يتفق اختيارها مع الاستخدام؟ وهل يستطيع فريق آخر إعادة تكوين النتيجة نفسها؟ إن إضافة قاعدة شكلية إلى ملف مبكر قد تخفي هذه الأسئلة بدلاً من الإجابة عنها.

بعض القرارات يقع خارج الملف الذي نتسلمه

النسخة التي فُحصت في 7 سبتمبر 2026 من مقترح الوحدات هي draft-ietf-cbor-cddl-modules-07، المؤرخة في 2 سبتمبر. وهي مسودة Internet-Draft قيد العمل، لا RFC منشوراً. وكان RFC 9682 قد أشار إلى نسخة أقدم.

تُكتب التوجيهات بصورة يمكن للأدوات الأساسية قراءتها كتعليقات. وهذا يتيح تصميم ملفات لبعض الاستخدامات المتوافقة، لكنه لا يضمن أن تجاهل توجيه ضروري سيعطي النموذج نفسه الذي ينتج عن معالجته. كما تميز المسودة بين تضمين القواعد واستيراد القواعد المرجعية مع تبعياتها. CDDL Module Structure، النسخة 07

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

تكمن أهمية ذلك في أن اسم الوحدة لا يكفي لتحديد المحتوى الذي دخل في النتيجة. فقد يوجد مصدران بالاسم نفسه في بيئتين مختلفتين. ويمكن أن يبقى الملف الرئيسي دون تعديل، بينما تختلف القواعد التي جرى إحضارها. حفظ الملف وحده لا يحفظ بالضرورة موضوع قرار القبول.

يساعد فصل نطاقات الأسماء على إدارة التصادم بين أسماء القواعد. لكنه لا يثبت مصدر البايتات المستخدمة. والثقة بالمصدر لا تثبت بمفردها أن الجذر المختار مناسب للغرض. لا ينبغي ضغط هذه القرارات المستقلة في عبارة واحدة تقول إن النموذج «تم التحقق منه».

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

دليل يرافق النموذج، لا مجرد شهادة للملف

الاقتراح العملي هنا هو حفظ سجل تركيب يربط محتوى المصادر، وإعدادات البحث، وإصدار المعالج، والجذر المحدد، والنموذج الناتج. هذا توصية تحريرية، لا متطلب إداري جديد يفرضه IETF.

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

تظهر فائدة السجل بعد مرور الوقت أيضاً. ربما يُنظَّف دليل محلي، أو تتغير مجموعة مرفقة بأداة، أو يغادر الشخص الذي يعرف إعدادات العمل القديمة. قد يظل الملف الرئيسي محفوظاً، بينما تضيع الظروف اللازمة لشرح ما وافقت عليه المؤسسة.

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

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