ما هي البدائل القابلة للاستخدام لبناء جملة XML التي تعرفها؟[مغلق]

Question

لي صالح للإستعمال يعني أن:

• يتم استخدامه في العالم الحقيقي
• لديها أدوات الدعم.(على الأقل بعض المحرر البسيط)
• يحتوي على بناء جملة يمكن قراءته بواسطة الإنسان (بدون أقواس زاوية من فضلك)

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

Answer 1

YAML عبارة عن مجموعة شاملة بنسبة 100% من JSON، لذلك ليس من المنطقي رفض YAML ثم التفكير في JSON بدلاً من ذلك.يقوم YAML بكل ما يفعله JSON، لكن YAML يقدم الكثير أيضًا (مثل المراجع).

لا أستطيع التفكير في أي شيء يمكن أن يفعله XML ولا يستطيع YAML القيام به، باستثناء التحقق من صحة المستند باستخدام DTD، والذي في تجربتي لم يكن يستحق كل هذا العناء.لكن YAML أسرع بكثير وأسهل في الكتابة والقراءة من XML.

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

<!-- XML -->
<Director name="Spielberg">
    <Movies>
        <Movie title="Jaws" year="1975"/>
        <Movie title="E.T." year="1982"/>
    </Movies>
</Director>


# YAML
Director: 
    name: Spielberg
    Movies:
      - Movie: {title: E.T., year: 1975}
      - Movie: {title: Jaws, year: 1982}

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

Answer 2

JSON يعد بديلاً جيدًا جدًا، وتوجد أدوات له بلغات متعددة.وهو حقًا سهل الاستخدام في عملاء الويب، لأنه جافا سكريبت أصلي.

Answer 3

لقد وجدت تعبيرات S لتكون طريقة رائعة لتمثيل البيانات المنظمة.إنه تنسيق بسيط جدًا يسهل إنشاؤه وتحليله.إنه لا يدعم السمات، ولكن مثل YAML وJSON، لا يحتاج إلى ذلك.السمات هي ببساطة وسيلة لـ XML للحد من الإسهاب.التنسيقات الأبسط والأنظف لا تحتاج إليها.

Answer 4

ليرة تركية؛ د

لم يتم ذكر Prolog هنا، ولكنه أفضل تنسيق أعرفه لتمثيل البيانات.تصف برامج Prolog، بشكل أساسي، قواعد البيانات، مع العلاقات المعقدة بين الكيانات.يعد Prolog سهل التحليل للغاية، ومن المحتمل أن يكون منافسه الوحيد هو تعبيرات S في هذا المجال.

النسخة الكاملة

غالبًا ما "ينسى" المبرمجون ما يتكون منه XML بالفعل.يشير عادةً إلى مجموعة فرعية صغيرة جدًا مما هو عليه.يعد XML تنسيقًا معقدًا للغاية، ويحتوي على هذه الأجزاء على الأقل: لغة مخطط DTD, لغة مخطط XSD, لغة تحويل XSLT, لغة مخطط RNG و XPath لغات (بالإضافة إلى XQuery) - جميعها جزء لا يتجزأ من معيار XML.بالإضافة إلى ذلك، هناك بعض مثل ابوكريفا إي 4 إكس.كل واحد منهم لديه نسخته الخاصة، وقدر كبير من التداخل، وعدم التوافق وما إلى ذلك.عدد قليل جدًا من موزعي XML في البرية ينفذونها جميعًا.ناهيك عن المراوغات والأخطاء المتعددة في التحليلات الشائعة، والتي يؤدي بعضها إلى مشكلات أمنية ملحوظة مثل https://en.wikipedia.org/wiki/XML_external_entity_attack .

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

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

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

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

Answer 5

كتب جيف عن هذا هنا و هنا.من المفترض أن يساعدك ذلك على البدء.

Answer 6

أود أن أوصي بـ JSON ...ولكن بما أنك ذكرت ذلك بالفعل، فربما ينبغي عليك إلقاء نظرة عليه مخازن بروتوكول جوجل.

يحرر:تم تصميم المخازن المؤقتة للبروتوكول لاستخدامها برمجيًا (توجد روابط لـ c++ وjava وpython...) لذا قد لا تكون مناسبة لغرضك.

Answer 7

طلباتك مستحيلة بعض الشيء ..تريد شيئًا قريبًا من XML، لكن من المحتمل أن ترفض أقرب معادل لا يحتوي على قوس زاوية (YAML).

بقدر ما لا يعجبني، لماذا لا أستخدم لغة XML فقط؟لا ينبغي عليك أبدًا قراءة XML فعليًا (بصرف النظر عن تصحيح الأخطاء، كما أفترض)، فهناك قدر سخيف من الأدوات اللازمة لذلك.

لن يتم استخدام أي شيء بخلاف XML على نطاق واسع، وبالتالي سيكون هناك دعم أقل للأدوات.

من المحتمل أن يكون JSON مكافئًا تقريبًا، لكنه غير قابل للقراءة إلى حد كبير.ولكن مرة أخرى، لا ينبغي عليك قراءتها فعليًا (قم بتحميلها بأي لغة تستخدمها، ويجب تحويلها إلى مصفوفات/إملاءات/متغيرات/أي شيء أصلي).

أوه، لقد وجدت JSON بعيد أجمل في التحليل من XML:لقد استخدمته في Javascript، ووحدة Simplejson Python - حول أمر واحد وتم تحويله بشكل جيد إلى إملاء Python أصلي، أو كائن Javascript (وبالتالي الاسم!)

Answer 8

هنالك محور عصبي التي تغطي أفضل ما في XML وJSON.ولنوضح ذلك بعدة أمثلة.

يمكن اعتبار AXON نموذجًا أقصر لبيانات XML.

XML

<person>
   <name>Frank Martin</name>
   <age>32</age>
 </person>

محور عصبي

person{
  name{"Frank Martin"}
  age{32}}

أو

person
  name:
    "Frank Martin"
  age:
    32

XML

<person name="Frank Martin" age="32" />

محور عصبي

person{name:"Frank Martin" age:32}

أو

person
  name: "Frank Martin"
  age: 32

يحتوي AXON على شكل من أشكال JSON.

JSON

{"name":"Frank Martin" "age":32 "birth":"1965-12-24"}

محور عصبي

{name:"Frank Martin" age:32 birth:1965-12-24}

يمكن أن يمثل AXON مجموعة من البيانات المشابهة لـ XML والبيانات المشابهة لـ JSON.

محور عصبي

table {
  fields {
    ("id" "int") ("val1" "double") ("val2" "int") ("val3" "double")
  }
  rows {
    (1 3.2 123 -3.4)
    (2 3.5 303 2.4)
    (3 2.3 235 -1.2)
  }
}

أو

table
  fields
    ("id" "int")
    ("val1" "double")
    ("val2" "int") 
    ("val3" "double")
  rows
    (1 3.2 123 -3.4)
    (2 3.5 303 2.4)
    (3 2.3 235 -1.2)

تتوفر مكتبة بايثون pyaxon الآن.

Answer 9

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

Answer 10

لتخزين البيانات الشبيهة بالرمز، ليه (بناء جملة Loyc Expression) هو بديل ناشئ.لقد لاحظت أن الكثير من الأشخاص يستخدمون لغة XML للبنيات المشابهة للتعليمات البرمجية، مثل أنظمة البناء التي تدعم الشروط الشرطية، واستدعاءات الأوامر، وحتى الحلقات في بعض الأحيان.هذه الأنواع من الأشياء تبدو طبيعية في LES:

// LES code has no built-in meaning. This just shows what it looks like.
[DelayedWrite]
Output(
    if version > 4.0 {
        $ProjectDir/Src/Foo;
    } else {
        $ProjectDir/Foo;
    }
);

ومع ذلك، لا يوجد بها دعم رائع للأدوات حتى الآن؛مكتبة LES الوحيدة حاليًا مخصصة لـ C#.يُعرف حاليًا تطبيق واحد فقط يستخدم LES: إل إل بي جي.وهو يدعم "السمات" ولكنها تشبه سمات C# أو تعليقات Java التوضيحية، وليست سمات XML.

من الناحية النظرية، يمكنك استخدام LES للبيانات أو العلامات، ولكن لا توجد معايير لكيفية القيام بذلك:

body {
    '''Click here to use the World's '''
    a href="http://google.com" {
        strong "most popular"; " search engine!"
    };
};

point = (2, -3);
tasteMap = { "lemon" -> sour; "sugar" -> sweet; "grape" -> yummy };

Answer 11

إذا كان لديك حساسية من الأقواس الزاوية، فإن JSON، HDF (كليرسيلفر)، و أوغدل هم الوحيدون الذين أعرفهم مرتجلاً.

وبعد قليل من البحث على Google، وجدت أيضًا قائمة بالبدائل هنا:
http://web.archive.org/web/20060325012720/www.pault.com/xmlalternatives.html

Answer 12

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

https://github.com/mojombo/toml

Answer 13

AFAIK وJSON وYAML متكافئون تمامًا من حيث بنية البيانات.يحتوي YAML على عدد أقل من الأقواس والاقتباسات والأشياء.لذلك لا أرى كيف ترفض أحدهما وتحتفظ بالآخر.

أيضًا، لا أرى كيف تكون الأقواس الزاوية في XML أقل "قابلية للقراءة البشرية" من الأقواس المربعة والأقواس المتعرجة والاقتباسات في JSON.

Answer 14

هناك بالفعل الكثير من البدائل لـ XML، ولكن يبدو أن المشكلة الرئيسية في الكثير منها هي أن المكتبات قد لا تكون متاحة لكل لغة من اختيارك وأن تنفيذ المكتبات شاق نسبيًا.

قد لا يكون تحليل بنية الشجرة في حد ذاته أمرًا ممتعًا، إذا ما قورن بأزواج القيمة الرئيسية، على سبيل المثال.جداول التجزئة.إذا كان مثيل جدول التجزئة يلبي متطلبات أن جميع مفاتيحه عبارة عن سلاسل وجميع قيمه عبارة عن سلاسل، فمن غير الشاق نسبيًا تنفيذ hashtable2string() و string2hashtable().

أنا أستخدم تسلسل جدول التجزئة في AJAX بين PHP وJavaScript والتنسيق الذي قمت بتطويره يسمى ProgFTE (تبادل النصوص الصديق للمبرمجين) ويتم وصفه في:

http://martin.softf1.com/g/n//a2/doc/progfte/index.html

يمكن العثور على إصدار Ruby من تطبيق ProgFTE كجزء من مكتبة Kibuvits Ruby:http://rubyforge.org/projects/kibuvits/