تم اختراع لغة XML في عام 1996. ولم يكد يظهر حتى بدأ يساء فهم إمكانيات تطبيقه بالفعل، ولم يكن الخيار الأفضل للأغراض التي كانوا يحاولون تكييفه من أجلها.
ليس من المبالغة القول إن الغالبية العظمى من مخططات XML التي رأيتها كانت استخدامات غير مناسبة أو غير صحيحة لـ XML. علاوة على ذلك، فإن هذا الاستخدام لـ XML أظهر سوء فهم أساسي لمعنى XML.
XML هي لغة ترميزية. هذا ليس تنسيق البيانات. لقد تجاهلت معظم مخططات XML هذا التمييز بوضوح، مما أدى إلى الخلط بين XML وتنسيق البيانات، مما أدى في النهاية إلى حدوث خطأ في اختيار XML لأنه تنسيق البيانات المطلوب بالفعل.
دون الخوض في الكثير من التفاصيل، يعتبر XML هو الأنسب لإضافة تعليقات توضيحية إلى كتل النص ذات البنية والبيانات الوصفية. إذا كان هدفك الرئيسي ليس العمل مع كتلة نصية، فمن غير المرجح أن يكون اختيار XML مبررًا.
من وجهة النظر هذه، هناك طريقة بسيطة للتحقق من مدى جودة إنشاء مخطط XML. لنأخذ كمثال مستندًا في المخطط المقصود ونزيل جميع العلامات والسمات منه. إذا كان ما تبقى غير منطقي (أو إذا كان هناك سطر فارغ متبقي)، فإما أن مخططك لم يتم إنشاؤه بشكل صحيح أو ببساطة لا ينبغي عليك استخدام XML.
سأقدم أدناه بعض الأمثلة الأكثر شيوعًا للدوائر التي تم إنشاؤها بشكل غير صحيح.
<roоt>
<item name="name" value="John" />
<item name="city" value="London" />
</roоt>نرى هنا مثالاً لمحاولة غريبة لا أساس لها من الصحة (وإن كانت شائعة جدًا) للتعبير عن قاموس قيمة مفتاح بسيط في XML. إذا قمت بإزالة كافة العلامات والسمات، فسوف يتبقى لك صف فارغ. في الأساس، هذه الوثيقة، بغض النظر عن مدى سخافتها، هي تعليق توضيحي دلالي لسطر فارغ.
<root name="John" city="London" />ولجعل الأمور أسوأ، ليس لدينا فقط تعليق توضيحي لسلسلة فارغة هنا كطريقة باهظة للتعبير عن القاموس - هذه المرة يتم ترميز "القاموس" مباشرة كسمات للعنصر الجذر. وهذا يجعل المجموعة المحددة من أسماء السمات على عنصر ما غير محددة وديناميكية. علاوة على ذلك، فهو يوضح أن كل ما أراد المؤلف التعبير عنه حقًا هو بناء جملة بسيط لقيمة المفتاح، ولكنه بدلاً من ذلك اتخذ قرارًا غريبًا تمامًا لتطبيق XML، مما اضطر إلى استخدام عنصر فارغ واحد ببساطة كبادئة لاستخدام بناء جملة السمة. وأنا أواجه مثل هذه المخططات في كثير من الأحيان.
<roоt>
<item key="name">John</item>
<item key="city">London</item>
</roоt>هذا شيء أفضل، ولكن الآن لسبب ما المفاتيح هي بيانات وصفية والقيم ليست كذلك. نظرة غريبة جدا على القواميس. إذا قمت بإزالة جميع العلامات والسمات، فسيتم فقدان نصف المعلومات.
سيبدو تعبير القاموس الصحيح في XML كما يلي:
<roоt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roоt>ولكن إذا اتخذ الأشخاص قرارًا غريبًا باستخدام لغة 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 هذا، ولكن لا فائدة من الجدال حول هذا الأمر نظرًا لأن المشكلة خارج نطاق مناقشة التنسيق نفسه. علاوة على ذلك، إذا جعلت المستند قابلاً للعرض في المتصفح عن طريق إرفاق ورقة أنماط متتالية به، فسترى أن عناصر القاموس تظهر بترتيب معين وليس بترتيب آخر.
وبعبارة أخرى، يمكن تحويل القاموس (قطعة من البيانات المنظمة) إلى n مختلف المستندات الممكنة (في XML، PDF، الورق، وما إلى ذلك)، حيث n - عدد المجموعات الممكنة من العناصر في القاموس، ولم نأخذ بعد في الاعتبار المتغيرات الأخرى المحتملة.
ومع ذلك، يترتب على ذلك أيضًا أنه إذا كنت تريد نقل البيانات فقط، فإن استخدام مستند يمكن قراءته آليًا لهذا لن يكون فعالاً. إنه يستخدم نموذجًا، وهو في هذه الحالة غير ضروري، ولن يؤدي إلا إلى عرقلة الطريق. بالإضافة إلى ذلك، من أجل استخراج البيانات المصدر، سوف تحتاج إلى كتابة برنامج. ليس هناك أي فائدة من استخدام XML لشيء لن يتم تنسيقه كمستند في مرحلة ما (على سبيل المثال، باستخدام CSS أو XSLT، أو كليهما)، لأن هذا هو السبب الرئيسي (إن لم يكن الوحيد) للقيام بذلك. إلى نموذج الوثيقة
علاوة على ذلك، نظرًا لأن XML لا يحتوي على مفهوم للأرقام (أو التعبيرات المنطقية أو أنواع البيانات الأخرى)، فإن جميع الأرقام الممثلة في هذا التنسيق تعتبر مجرد نص إضافي. لاستخراج البيانات، يجب معرفة المخطط وعلاقته بالبيانات المقابلة التي يتم التعبير عنها. تحتاج أيضًا إلى معرفة متى يمثل عنصر نص معين رقمًا، بناءً على السياق، ويجب تحويله إلى رقم، وما إلى ذلك.
وبالتالي، فإن عملية استخراج البيانات من مستندات XML لا تختلف كثيرًا عن عملية التعرف على المستندات الممسوحة ضوئيًا التي تحتوي، على سبيل المثال، على جداول تشكل صفحات عديدة من البيانات الرقمية. نعم، من الممكن القيام بذلك من حيث المبدأ، ولكن هذه ليست الطريقة الأمثل، إلا كحل أخير، عندما لا تكون هناك خيارات أخرى على الإطلاق. الحل المعقول هو ببساطة العثور على نسخة رقمية من البيانات الأصلية غير المضمنة في نموذج مستند يجمع البيانات مع تمثيلها النصي المحدد.
ومع ذلك، لا يفاجئني على الإطلاق أن لغة XML تحظى بشعبية كبيرة في مجال الأعمال. والسبب في ذلك هو أن تنسيق المستند (على الورق) مفهوم ومألوف للأعمال، ويريدون الاستمرار في استخدام نموذج مألوف ومفهوم. لنفس السبب، غالبًا ما تستخدم الشركات مستندات PDF بدلاً من التنسيقات الأكثر قابلية للقراءة آليًا - لأنها لا تزال مرتبطة بمفهوم الصفحة المطبوعة بحجم مادي محدد. وينطبق هذا أيضًا على المستندات التي من غير المرجح أن تتم طباعتها على الإطلاق (على سبيل المثال، ملف PDF مكون من 8000 صفحة من وثائق التسجيل). من وجهة النظر هذه، فإن استخدام لغة XML في الأعمال التجارية هو في الأساس مظهر من مظاهر التشكل. يفهم الناس الفكرة المجازية للصفحة المطبوعة ذات الحجم المحدود، ويفهمون كيفية إنشاء عمليات تجارية تعتمد على المستندات المطبوعة. إذا كان هذا هو دليلك، فإن المستندات التي لا تحتوي على قيود الحجم الفعلي والتي يمكن قراءتها بواسطة الآلة - مستندات XML - تمثل ابتكارًا في حين أنها نظير مستند مألوف ومريح. هذا لا يمنعهم من البقاء بطريقة غير صحيحة ومبالغ فيها في تقديم البيانات.
حتى الآن، مخططات XML الوحيدة التي أعرفها والتي يمكنني اعتبارها حقًا استخدامًا صالحًا للتنسيق هي XHTML وDocBook.
المصدر: www.habr.com