تم اختراع لغة XML في عام 1996. بالكاد ظهر قبل أن يساء فهم إمكانات تطبيقه ، وللأغراض التي حاولوا تكييفه من أجله ، لم يكن هو الخيار الأفضل.
لن يكون من المبالغة القول إن الغالبية العظمى من مخططات XML التي رأيتها غير ملائمة أو إساءة استخدام XML. علاوة على ذلك ، شهد استخدام XML هذا على سوء فهم أساسي لما يتعلق به XML أساسًا.
XML هي لغة الترميز.
هذا ليس تنسيق بيانات . في معظم مخططات XML ، لم يؤخذ هذا التمييز في الاعتبار بشكل صريح ، ما يربك XML مع تنسيق البيانات ، مما يعني في النهاية خطأً في اختيار XML ، لأنه في الواقع كانت هناك حاجة إلى تنسيق البيانات.
دون الخوض في التفاصيل ، يعد XML هو الأفضل لتعليق كتل النص بالبنية والبيانات الأولية. إذا لم تكن مهمتك الرئيسية التعامل مع مجموعة نصية ، فمن غير المحتمل أن يكون اختيار XML مبررًا.
من وجهة النظر هذه ، هناك طريقة سهلة للتحقق من مدى جودة مخطط XML. خذ على سبيل المثال المستند في المخطط المقترح وقم بإزالة جميع العلامات والسمات منه. إذا لم يكن هناك أي نقطة فيما تبقى (أو إذا بقيت سلسلة فارغة) ، فلن يتم بناء المخطط الخاص بك بشكل صحيح ، وإلا فلن يكون عليك استخدام XML.
أدناه ، سأقدم بعض الأمثلة الأكثر شيوعًا للدوائر التي تم إنشاؤها بشكل غير صحيح.
<rot> <item name="name" value="John" /> <item name="city" value="London" /> </rot>
نرى هنا مثالاً لمحاولة غير معقولة وغريبة (وإن كانت واسعة الانتشار) للتعبير عن قاموس بسيط ذي قيمة رئيسية في XML. إذا حذفت جميع العلامات والسمات ، فسيظل هناك سطر فارغ. في الأساس ، هذا المستند هو ، بغض النظر عن مدى سخفه ، التعليق التوضيحي الدلالي لخط فارغ.
<root name="John" city="London" />
ومما زاد الطين بلة ، ما لدينا هنا ليس مجرد تعليق توضيحي دلالي لسلسلة فارغة كوسيلة باهظة للتعبير عن القاموس - وهذه المرة يتم ترميز "القاموس" مباشرة كسمات لعنصر الجذر. لهذا السبب ، تصبح مجموعة معينة من أسماء السمات على عنصر غير محددة وديناميكية. علاوة على ذلك ، من الواضح من هنا أن كل ما أراد المؤلف التعبير عنه هو بناء جملة بسيط لقيمة المفتاح ، لكنه بدلاً من ذلك اتخذ قرارًا غريبًا تمامًا باستخدام XML ، مما فرض استخدام عنصر فارغ واحد تمامًا كبادئة للاستخدام بناء جملة السمة. ومثل هذه المخططات تأتي لي في كثير من الأحيان.
<rot> <item key="name">John</item> <item key="city">London</item> </rot>
هذا بالفعل شيء أفضل ، لكن المفاتيح الآن هي بيانات وصفية لسبب ما ، لكن القيم ليست كذلك. نظرة غريبة جدا على القواميس. إذا حذفت جميع العلامات والسمات ، فسيُفقد نصف المعلومات.
سيبدو تعبير القاموس الصحيح في XML شيئًا مثل هذا:
<rot> <item> <key>Name</key> <value>John</value> </item> <item> <key>City</key> <value>London</value> </item> </rot>
ولكن إذا اتخذ الأشخاص القرار الغريب في استخدام XML كتنسيق بيانات ثم استخدامه لتنظيم القاموس ، فعليهم أن يفهموا أن ما يفعلونه غير مناسب وغير مناسب. لا يزال المصممون يختارون عن طريق الخطأ XML لبناء تطبيقاتهم. ولكن في كثير من الأحيان ، فإنها تؤدي إلى تفاقم الموقف من خلال استخدام XML بدون معنى في أحد النماذج الموضحة أعلاه ، متجاهلة حقيقة أن XML ببساطة غير مناسب لهذا.
أسوأ مخطط XML؟ بالمناسبة ، تحصل جائزة
أسوأ مخطط XML رأيته على
الإطلاق على تنسيق ملف تكوين تخصيص الموارد التلقائي لهواتف Polycom IP الهاتفية. تتطلب هذه الملفات تحميل ملفات طلب XML عبر TFTP ، والتي ... بشكل عام ، إليك مقتطف من أحد هذه الملفات:
<softkey softkey.feature.directories="0" softkey.feature.buddies="0" softkey.feature.forward="0" softkey.feature.meetnow="0" softkey.feature.redial="1" softkey.feature.search="1" softkey.1.enable="1" softkey.1.use.idle="1" softkey.1.label="Foo" softkey.1.insert="1" softkey.1.action="..." softkey.2.enable="1" softkey.2.use.idle="1" softkey.2.label="Bar" softkey.2.insert="2" softkey.2.action="..." />
هذه ليست مزحة سيئة. وهذا ليس اختراعي:
- تستخدم العناصر ببساطة كبادئة لإرفاق السمات ، والتي لها أسماء هرمية بحد ذاتها.
- إذا كنت تريد تعيين قيم إلى عدة مثيلات لسجل من نوع معين ، فأنت بحاجة إلى استخدام أسماء السمات التي توجد بها فهارس .
- بالإضافة إلى ذلك ، السمات التي تبدأ بـ
softkey. ، تحتاج إلى وضع على عناصر <softkey/> ، السمات التي تبدأ feature. ، يجب وضعه على عناصر <feature/> ، وما إلى ذلك ، على الرغم من حقيقة أنها تبدو زائدة عن الحاجة ولا تبدو عديمة الجدوى للوهلة الأولى.
- وأخيرًا ، إذا كنت تأمل أن يتطابق المكون الأول من اسم السمة دائمًا مع اسم العنصر - لا شيء من هذا القبيل! على سبيل المثال ، سمات
up. يجب إرفاقه بـ <userpreferences/> . ترتيب ربط أسماء السمات بالعناصر أمر تعسفي ، ويكاد يكون كاملاً.
المستندات أو البيانات . من وقت لآخر ، يقوم شخص ما بأشياء غريبة تمامًا ، حيث يحاول مقارنة XML و JSON - ومن ثم يظهر أنه لا يفهم أحدهما أو الآخر. XML هي لغة ترميز المستند. JSON هو تنسيق بيانات منظم ، لذا فإن المقارنة بينه وبين الآخر يشبه محاولة المقارنة بين الحارة والناعمة.
لفهم هذا ، سوف يساعد مفهوم الفرق بين
المستندات والبيانات . كنسخة تماثلية لـ XML ، يمكنك التقاط مستند يمكن قراءته آليًا بشكل تعسفي. على الرغم من أنه يُقصد قراءتها بواسطة جهاز ، إلا أنه يشير بشكل مجازي إلى المستندات ، ومن وجهة النظر هذه ، فإنه يشبه في الواقع مستندات PDF ، والتي غالبًا ما تكون غير قابلة للقراءة آليًا.
على سبيل المثال ، في XML ، يكون ترتيب العناصر مهمًا. وفي JSON ، ليس ترتيب أزواج القيمة الرئيسية داخل الكائنات منطقيًا ولم يتم تعريفه. إذا كنت ترغب في الحصول على قاموس غير مرتب من أزواج قيمة المفتاح ، فلا يهم الترتيب الفعلي الذي تتبعه العناصر الموجودة في هذا الملف. لكن يمكنك تكوين العديد من
المستندات المختلفة من هذه البيانات ، لأن المستند له ترتيب معين. بشكل مجازي ، هذا هو تناظر وثيقة على الورق ، على الرغم من أنه لا يحتوي على أبعاد مادية ، على عكس النسخة المطبوعة أو ملف PDF.
في مثالي للتمثيل الصحيح للقاموس في XML ، يتم عرض ترتيب العناصر في القاموس ، على عكس التمثيل في لغة JSON. لا يمكنني تجاهل هذا الترتيب: مثل هذا الخطي ملازم لنموذج المستند وتنسيق XML. عند تفسير مستند XML هذا ، قد يقرر شخص ما تجاهل هذا الترتيب ، لكن لا جدال من الجدال حول هذا الموضوع ، لأن هذه المشكلة تتجاوز مناقشة التنسيق نفسه. علاوة على ذلك ، إذا جعلت المستند قابلاً للعرض في المستعرض عن طريق إرفاق ورقة أنماط متتالية به ، يمكنك أن ترى أن عناصر القاموس تتبع بترتيب معين ، وليس بأي طريقة أخرى.
بمعنى آخر ، يمكن تحويل قاموس (جزء من البيانات المهيكلة) إلى مستندات محتملة مختلفة (في XML ، PDF ، على الورق ، وما إلى ذلك) ، حيث
n هو عدد مجموعات العناصر الممكنة في القاموس ، ولم نأخذ في الاعتبار الآخرين بعد المتغيرات المحتملة.
ومع ذلك ، يستنتج أيضًا من ذلك أنه إذا كنت تريد نقل البيانات بمفردها ، فلن يكون استخدام مستند مقروء آليًا لهذا الغرض فعالًا. يستخدم نموذجًا ، وهو في هذه الحالة لا لزوم له ، وسوف يتداخل فقط. بالإضافة إلى ذلك ، من أجل استخراج البيانات المصدر ، سيكون من الضروري لكتابة برنامج. بالكاد يكون من المنطقي استخدام XML لشيء لن يتم تنسيقه في مرحلة معينة كمستند (على سبيل المثال ، استخدام CSS أو XSLT ، أو كليهما) ، لأن هذا هو السبب الرئيسي (إن لم يكن السبب الوحيد) لذلك التمسك نموذج المستند.
علاوة على ذلك ، نظرًا لأن XML لا يحتوي على مفهوم الأرقام (أو التعبيرات المنطقية ، أو أنواع البيانات الأخرى) ، فإن جميع الأرقام الممثلة في هذا التنسيق تعتبر نصًا إضافيًا فقط. لاستخراج البيانات ، يجب معرفة المخطط وعلاقته بالبيانات المعبر عنها المقابلة. من الضروري أيضًا معرفة متى ، بناءً على السياق ، يكون عنصر أو عنصر من عناصر النص هو رقم ، ويجب تحويله إلى رقم ، إلخ.
وبالتالي ، فإن عملية استخراج البيانات من مستندات XML لا تختلف كثيرًا عن عملية التعرف على المستندات الممسوحة ضوئيًا والتي تحتوي ، على سبيل المثال ، على الجداول التي تشكل العديد من صفحات البيانات الرقمية. نعم ، من الممكن من حيث المبدأ القيام بذلك ، لكن هذه ليست الطريقة المثلى ، إلا في حالة متطرفة ، عندما لا توجد خيارات أخرى على الإطلاق. سيكون القرار الذكي هو العثور ببساطة على نسخة رقمية من البيانات الأصلية غير المضمنة في نموذج المستند ، حيث يتم دمج البيانات مع تمثيلها النصي المحدد.
ومع ذلك ، لا يفاجئني أبدًا أن XML شائع في الأعمال التجارية. السبب في ذلك بالتحديد هو أن تنسيق المستندات (على الورق) مفهوم ومألوف لدى الشركات ، ويريدون الاستمرار في استخدام النموذج المألوف والمفهوم هناك. للسبب نفسه ، في الأعمال التجارية غالبًا ما يستخدمون المستندات في PDF بدلاً من أن يكونوا أكثر ملاءمة لتنسيقات معالجة الماكينة - لأنها لا تزال مرتبطة بمفهوم الصفحة المطبوعة ذات حجم مادي معين. ينطبق هذا حتى على المستندات التي من غير المحتمل أن تتم طباعتها (على سبيل المثال ، ملف PDF من وثائق التسجيل من 8000 صفحة). من وجهة النظر هذه ، فإن استخدام XML في الأعمال التجارية هو في الأساس مظهر من مظاهر الانحراف اللغوي. يفهم الناس الفكرة المجازية لصفحة مطبوعة ذات حجم محدود ، ويفهمون كيفية إنشاء عمليات تجارية بناءً على المستندات المطبوعة. إذا كان هذا هو المبدأ التوجيهي الخاص بك ، فالمستندات التي ليس لها حجم فعلي محدود وقابلة للقراءة آليًا - مستندات XML - تعد ابتكارًا ، بينما تكون تماثلًا مألوفًا ومريحًا للمستند. وهو ما لا يمنعهم من البقاء بطريقة غير صحيحة وغير صحيحة بشكل مفرط في تقديم البيانات.
حتى الآن ، فإن مخططات XML الوحيدة التي أعرف أنه يمكنني حقًا الاتصال بالاستخدام السليم لهذا التنسيق هي XHTML و DocBook.