ما هي نقاط ضعف XML؟ [مغلق

Question

عند قراءة StackOverflow والاستماع إلى Podcasts لـ Joel Spolsky و Jeff Atwood ، أبدأ في الاعتقاد بأن العديد من المطورين يكرهون استخدام XML أو على الأقل حاول تجنب استخدام XML قدر الإمكان لتخزين البيانات أو تبادلها.

من ناحية أخرى ، أستمتع باستخدام XML كثيرًا لعدة أسباب:

• يتم تنفيذ تسلسل XML في معظم اللغات الحديثة وهو سهل الاستخدام للغاية,
• كونه أبطأ من التسلسل الثنائي ، فإن تسلسل XML مفيد للغاية عندما يتعلق الأمر استخدام نفس البيانات من عدة لغات البرمجة أو حيث يهدف إلى القراءة والفهم ، حتى بالنسبة للتصحيح ، من قبل الإنسان (JSON ، على سبيل المثال ، يصعب فهمه) ،
• يدعم XML يونيكود, ، وعند استخدامها بشكل صحيح ، لا توجد مشاكل في الترميز والأحرف المختلفة وما إلى ذلك.
• هناك الكثير من الأدوات التي تجعل من السهل العمل مع بيانات XML. XSLT مثال على ذلك ، مما يجعل من السهل تقديمها وتحويل البيانات. xpath هل هو واحد آخر ، مما يجعل من السهل البحث عن البيانات ،
• يمكن تخزين XML في بعض خوادم SQL ، والتي تتيح السيناريوهات عند البيانات التي تكون معقد للغاية بحيث لا يمكن تخزينه بسهولة في طاولات SQL يجب حفظها والتلاعب بها ؛ على سبيل المثال ، لا يمكن التلاعب بالبيانات JSON أو الثنائية من خلال SQL مباشرة (باستثناء معالجة السلاسل ، وهو أمر مجنون في معظم المواقف) ،
• لا تتطلب XML تثبيت أي تطبيقات. إذا كنت أرغب في استخدام تطبيق قاعدة البيانات ، فيجب عليك تثبيت خادم قاعدة البيانات أولاً. إذا أردت أن يستخدم تطبيقي XML ، لست مضطرًا لتثبيت أي شيء,
• XML أكثر بكثير واضحة وقابلة للتمديد على سبيل المثال ، على سبيل المثال ، سجلات Windows أو ملفات INI ،
• في معظم الحالات ، هناك لا مشاكل CR-LF, ، بفضل مستوى التجريد الذي توفره XML.

لذا ، مع الأخذ في الاعتبار جميع فوائد استخدام XML ، لماذا يكره الكثير من المطورين استخدامه؟ IMHO ، المشكلة الوحيدة في ذلك هي:

• XML مطول للغاية ويتطلب مكانًا أكبر بكثير من معظم أشكال البيانات الأخرى ، خاصةً عندما يتعلق الأمر بترميز BASE64.

بالطبع ، هناك العديد من السيناريوهات التي لا تتناسب فيها XML على الإطلاق. تخزين الأسئلة والإجابات SO في ملف XML على جانب الخادم سيكون خطأ تماما. أو عند تخزين فيديو AVI أو مجموعة من صور JPG ، فإن XML هو أسوأ شيء يجب استخدامه.

ولكن ماذا عن السيناريوهات الأخرى؟ ما هي نقاط ضعف XML؟

---

للأشخاص الذين اعتبروا أن هذا السؤال ليس سؤالًا حقيقيًا:

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

ولكن إنها ويكي ، لأنه لا يمكن أن يكون هناك فريدة من نوعها إجابة جيدة على هذا السؤال.

وفقًا لذلك ، "ليس سؤالًا حقيقيًا" هو سؤال أين "من الصعب معرفة ما يتم طرحه هنا. هذا السؤال غامض أو غامض أو غير مكتمل أو خطابي ولا يمكن الإجابة عليه بشكل معقول في شكله الحالي."

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

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

Answer 1

بعض نقاط الضعف:

• من الصعب إلى حد ما ربط ملفات XML والموارد الخارجية ، وهذا هو السبب في أن تنسيقات مستندات Office الجديدة تستخدم مغلفًا مضغوطًا يتضمن ملفات XML للهيكل العظمي وملفات الموارد المجمعة معًا. الخيار الآخر لاستخدام ترميز BASE64 هو مطوّل للغاية ولا يسمح بوصول عشوائي جيد ، مما يجلب واحدة إلى النقطة التالية:
• الوصول العشوائي صعب. لا يتيح أي من الوضعين التقليديين لقراءة ملف XML - إنشاء DOM أو قراءة نمط SAX فقط فقط للوصول العشوائي حقًا.
• يعد الوصول إلى الكتابة المتزامنة إلى أجزاء مختلفة من الملف أمرًا صعبًا ، وهذا هو السبب في أن استخدامه في ظهور Windows قابل للتنفيذ أمر عرضة للخطأ.
• ما هو الترميز الذي يستخدمه ملف XML؟ بالمعنى الدقيق للكلمة ، تخمن الترميز أولاً ، ثم اقرأ الملف والتحقق من أن الترميز كان صحيحًا.
• من الصعب إصدار أجزاء من الملف. لذلك إذا كنت ترغب في توفير إصدار حبيبتي ، فأنت بحاجة إلى تقسيم بياناتك. هذه ليست مجرد مشكلة تنسيق الملف ، ولكن أيضًا بسبب حقيقة أن الأدوات توفر عمومًا دلالات لكل ملف - أدوات التحكم في الإصدار ، وأدوات المزامنة مثل Dropbox ، إلخ.

Answer 2

<xml>
    <noise>
        The
    </noise>
    <adjective>
        main
    </adjective>
    <noun>
        weakness
    </noun>
    <noise>
        of
    </noise>
    <subject>
        XML
    </subject>
    <noise>
        ,
    </noise>
    <whocares>
        in my opinion
    </whocares>
    <noise>
        ,
    </noise>
    <wildgeneralisation>
        is its verbosity
    </wildgeneralisation>
    <noise>
        .
    </noise>
</xml>

Answer 3

أنا لست الشخص المناسب لأسأل ، لأنني معجب كبير بـ XML بنفسي. ومع ذلك ، يمكنني أن أخبركم واحدة من الشكاوى الرئيسية التي سمعت بها:

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

Answer 4

أعتقد بشكل عام أن رد الفعل هو ببساطة لأن XML مفرط الاستخدام.

ومع ذلك ، إذا كانت هناك كلمة واحدة أكرهها حول XML ، بشغف ، هي مساحات الأسماء. الإنتاجية المفقودة حول مشاكل مساحة الاسم مروعة.

Answer 5

ينحدر XML من SGML ، الحفيد العظيم لغات الترميز. الغرض من SGML وبالتالي XML هو نص التعليق. تقوم XML بذلك بشكل جيد ولديها مجموعة واسعة من الأدوات التي تزيد من منشأتها لمجموعة متنوعة من التطبيقات.

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

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

شخصيا ، أجد ذلك يامل يجلب توازنًا لطيفًا بين الطرفين. قارن ما يلي (نسخ من yaml.org مع تغييرات طفيفة).

يامل:

invoice: 34843
  date: 2001-01-23
  billto: &id001
    given: Chris
    family: Dumars
    address:
      lines: |
        458 Walkman Dr.
        Suite #292
      city: Royal Oak
      state: MI
      postal: 48046
  shipto: *id001
  product:
  - sku: BL394D
    quantity: 4
    description: Basketball
    price: 450.00
  - sku: BL4438H
    quantity: 1
    description: Super Hoop
    price: 2392.00
  tax : 251.42
  total: 4443.52
  comments: >
    Late afternoon is best.
    Backup contact is Nancy
    Billsmer @ 338-4338.

XML:

<invoice>
   <number>34843</number>
   <date>2001-01-03</date>
   <billto id="id001">
      <given>Chris</given>
      <family>Dumars</family>
      <address>
        <lines>
          458 Walkman Dr.
          Suite #292
        </lines>
        <city>Royal Oak</city>
        <state>MI</state>
        <postal>48046</postal>
      </address>
   </billto>
   <shipto xref="id001" />
   <products>
      <product>
        <sku>BL394D</sku>
        <quantity>4</quantity>
        <description>Basketball</description>
        <price>450.00</price>
      </product>
      <product>
        <sku>BL4438</sku>
        <quantity>1</quantity>
        <description>Super Hoop</description>
        <price>2392.00</price>
      </product>
   </products>
   <tax>251.42</tax>
   <total>4443.52</total>
   <comments>
    Late afternoon is best. Backup contact is Nancy Billsmer @ 338-4338
   </comments>
</invoice>

كلاهما يمثل نفس البيانات ، لكن YAML يزيد عن 30 ٪ أصغر ويمكن القول أنه أكثر قابلية للقراءة. ما الذي تفضل تعديله مع محرر نصوص؟ هناك العديد من المكتبات المتاحة للحالة وينبعث YAML (أي SnakeyAml لمطوري Java).

كما هو الحال مع كل شيء ، فإن الأداة المناسبة للوظيفة الصحيحة هي أفضل قاعدة يجب اتباعها.

Answer 6

مشكلتي المفضلة المفضلة هي تنسيقات التسلسل XML التي تستخدم السمات - مثل XAML.

هذا يعمل:

<ListBox ItemsSource="{Binding Items}" SelectedItem="{Binding CurrentSelection}"/>

هذا لا:

<ListBox SelectedItem="{Binding CurrentSelection}" ItemsSource="{Binding Items}"/>

يقوم Deserialization XAML بتعيين قيم الخصائص أثناء قراءتها من دفق XML. لذلك في المثال الثاني ، عندما SelectedItem تم تعيين الخاصية ، والتحكم ItemsSource لم يتم تعيينه بعد ، و SelectedItem يتم تعيين الخاصية لعنصر يعرف بعد.

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