الخلاصة

  • يعرّف RFC 3648 الترتيب بوصفه حالة للمجموعة، لكنه يسمح في MOVE داخل الأب نفسه بالحفاظ على الموضع أو بالحذف ثم الإضافة، فتذهب العضوية إلى النهاية إذا غاب Position.
  • لا يصبح before أو after دليلاً إلا مع لقطة عضوية صالحة وصلاحية وقفل وطلب محفوظ وقراءة PROPFIND بعمق 1 ومشاهدة للعرض النهائي.

في RFC 3648، لا تَعِد المجموعة غير المرتبة بتكرار ترتيب نتائج PROPFIND. أما المجموعة المرتبة فعلى الخادم أن يتبع تسلسلها، وأن يظهر كل عضو داخلي مرة واحدة من دون إدخال غير الأعضاء. لذلك فالترتيب حالة قابلة للملاحظة، لا مجرد تفضيل في واجهة المستخدم.

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

يحمل الحقل Position قيم first وlast وbefore وafter، وما زال مسجلاً في سجل IANA لحقول HTTP. لكن المقطع المشار إليه يجب أن يكون عضواً حالياً وألا يكون هو العضو المتأثر. يعرّف RFC شرطَي DAV:collection-must-be-ordered وDAV:segment-must-identify-member. فإذا اختفى المرجع، فليس على الخادم اختراع نية بديلة.

العضوية ليست السلطة. يخضع ترتيب المجموعة لأقفالها وضوابط الوصول. يوفّر RFC 3744 طبقة التحكم بالوصول في WebDAV؛ معرفة URI أو اسم المقطع لا تمنح حق إعادة الترتيب. ويجب أن يحتفظ السجل بقرار الصلاحية والقفل إلى جانب الطلب، لا أن يستنتجه من معرفة الاسم.

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

الخاصية المحمية DAV:ordering-type تصف الدلالة. DAV:custom يعلن وجود ترتيب من دون معنى محمول بين التطبيقات، وDAV:unordered ينفي ضمان التكرار. ويمكن أن تكون قيمة النوع URI، لكن المعيار يحذر من جلبها تلقائياً كي لا يُدفع عدد كبير من العملاء إلى هدف واحد. إنها تسمية للمعنى وليست خدمة واجبة الاستدعاء.

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

القراءة المباشرة هي PROPFIND بعمق 1. أما Depth: infinity فقد يمزج أحفاد مجموعات متعددة مع الحفاظ على ترتيب كل مجموعة محلياً، ولذلك لا ينتج تسلسلاً عالمياً مسطحاً. كان RFC 2518 أساس WebDAV الذي استند إليه النص، ثم حل محله RFC 4918؛ ولا يحوّل أي منهما رمز النجاح إلى شهادة للواجهة.

يضيف RFC 3253 آليات DeltaV. يسجل إصدار المجموعة نوع الترتيب وترتيب الأعضاء الخاضعين للتحكم بالإصدار، لكن موضع الأعضاء غير الخاضعين له بعد UPDATE أو MERGE يحدده الخادم. يجب إذاً قراءة القائمة الكاملة بعد الاستعادة.

الدعم اختياري ويُكتشف لكل مورد عبر OPTIONS وفئة ordered-collections وAllow والخصائص الحية. يوسع RFC 5689 MKCOL، لكن قبول جسم موسع لا يثبت تطبيق ترتيب بعينه. ويمكن لآليات الشرط والتحقق في RFC 7232 وRFC 9110 أن تساعد تنفيذاً محدداً؛ غير أن RFC 3648 لا يعرف رمز مراجعة خاصاً بالترتيب.

يأتي مفهوم segment من RFC 2396، بينما حدّث RFC 3986 نحو URI العام. المقطع في before أو after مُعامل مرتبط بعضوية لحظية، وليس هوية دائمة أو رمز تفويض.

يمكن التحقق من أصل الوثيقة عبر Datatracker وصفحة معلومات RFC Editor والسجل التاريخي والتصحيحات. هذه مصادر للنص وليست قياساً للخوادم المنتشرة.

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

ينبغي أن يجمع الإيصال هوية المجموعة وURI ونوع الترتيب والقائمة السابقة الكاملة والقدرات والعضوية المرجعية وقرار ACL والقفل وبايتات MOVE أو ORDERPATCH وPosition والاستجابة وقائمة Depth: 1 اللاحقة وأي إصدار أو validator مكشوف وترتيب العرض. كل فجوة تظل عدم يقين معلناً.