سمة XML مقابل عنصر XML

Question

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

العينة التي توصلت إليها هي في الأساس شيء من هذا القبيل:

<INVENTORY>
   <ITEM serialNumber="something" location="something" barcode="something">
      <TYPE modelNumber="something" vendor="something"/> 
   </ITEM>
</INVENTORY>

قال الفريق الآخر إن هذا لم يكن معيارًا صناعيًا ويجب استخدام السمات فقط للبيانات التعريفية.واقترحوا:

<INVENTORY>
   <ITEM>
      <SERIALNUMBER>something</SERIALNUMBER>
      <LOCATION>something</LOCATION>
      <BARCODE>something</BARCODE>
      <TYPE>
         <MODELNUMBER>something</MODELNUMBER>
         <VENDOR>something</VENDOR>
      </TYPE>
   </ITEM>
</INVENTORY>

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

بعد الشرح الطويل (آسف)، كيف يمكنك تحديد ما هي البيانات الوصفية، وعند تصميم بنية مستند XML، كيف يجب أن تقرر متى تستخدم سمة أو عنصرًا؟

Answer 1

أستخدم هذه القاعدة الأساسية:

1. السمة هي شيء قائم بذاته، أي اللون، والمعرف، والاسم.
2. العنصر هو شيء له أو يمكن أن يكون له سمات خاصة به أو يحتوي على عناصر أخرى.

إذن أمرك قريب.كنت سأفعل شيئًا مثل:

يحرر:تم تحديث المثال الأصلي بناءً على التعليقات الواردة أدناه.

  <ITEM serialNumber="something">
      <BARCODE encoding="Code39">something</BARCODE>
      <LOCATION>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

Answer 2

بعض المشاكل مع السمات هي:

• لا يمكن أن تحتوي السمات على قيم متعددة (يمكن للعناصر الفرعية)
• السمات ليست قابلة للتوسيع بسهولة (للتغييرات المستقبلية)
• لا يمكن للسمات وصف الهياكل (يمكن للعناصر الفرعية)
• من الصعب التعامل مع السمات بواسطة كود البرنامج
• ليس من السهل اختبار قيم السمات مقابل DTD

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

لا ينتهي الأمر بهذا الشكل (ليست هذه هي الطريقة التي ينبغي بها استخدام XML):

<note day="12" month="11" year="2002" 
      to="Tove" to2="John" from="Jani" heading="Reminder"  
      body="Don't forget me this weekend!"> 
</note>

مصدر: http://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp

Answer 3

يشير "XML" إلى "eXtensible". وضع علامة على لغة".تشير لغة الترميز إلى أن البيانات عبارة عن نص، تم ترميزه مع البيانات الوصفية حول الهيكل أو التنسيق.

XHTML هو مثال على استخدام XML بالطريقة المقصودة:

<p><span lang="es">El Jefe</span> insists that you
    <em class="urgent">MUST</em> complete your project by Friday.</p>

وهنا يتضح الفرق بين العناصر والصفات.يتم عرض عناصر النص في المتصفح، وتكون السمات عبارة عن تعليمات حولها كيف لعرضها (على الرغم من وجود بعض العلامات التي لا تعمل بهذه الطريقة).

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

Answer 4

عنصر XML مقابل سمة XML

XML هو كل شيء عن الاتفاق. قم أولاً بالتأجيل إلى أي مخططات XML موجودة أو اتفاقيات قائمة داخل مجتمعك أو صناعتك.

إذا كنت حقًا في وضع يسمح لك بتحديد مخططك من الألف إلى الياء، فإليك بعض الاعتبارات العامة التي ينبغي أن تفيدك قرار العنصر مقابل السمة:

<versus>
  <element attribute="Meta content">
    Content
  </element>
  <element attribute="Flat">
    <parent>
      <child>Hierarchical</child>
    </parent>
  </element>
  <element attribute="Unordered">
    <ol>
      <li>Has</li>
      <li>order</li>
    </ol>
  </element>
  <element attribute="Must copy to reuse">
    Can reference to re-use
  </element>
  <element attribute="For software">
    For humans
  </element>
  <element attribute="Extreme use leads to micro-parsing">
    Extreme use leads to document bloat
  </element>
  <element attribute="Unique names">
    Unique or non-unique names
  </element>
  <element attribute="SAX parse: read first">
    SAX parse: read later
  </element>
  <element attribute="DTD: default value">
    DTD: no default value
  </element>
</versus>

Answer 5

قد يعتمد ذلك على استخدامك.قد يعمل XML المستخدم لتمثيل البيانات المنظمة التي تم إنشاؤها من قاعدة بيانات بشكل جيد مع وضع قيم الحقول في النهاية كسمات.

ومع ذلك، غالبًا ما يكون استخدام XML كوسيلة لنقل الرسائل أفضل باستخدام المزيد من العناصر.

على سبيل المثال لنفترض أن لدينا ملف XML هذا كما هو مقترح في الإجابة: -

<INVENTORY>
   <ITEM serialNumber="something" barcode="something">
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
    </ITEM>
</INVENTORY>

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

   <ITEM serialNumber="something">
      <barcode encoding="Code39">something</barcode>
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

النقطة المهمة هي أنه ما لم تقم ببناء نوع من XSD أو DTD مع مساحة اسم لإصلاح الهيكل في الحجر، فقد يكون من الأفضل ترك خياراتك مفتوحة.

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

Answer 6

أستخدم الإرشادات التالية في تصميم المخطط الخاص بي فيما يتعلق بالسمات مقابل السمات.عناصر:

• استخدم عناصر لنص طويل المدى (عادةً ما تكون أنواع السلسلة أو أنواع الطبيعات)
• لا تستخدم سمة إذا كان هناك تجميع لقيمتين (على سبيل المثال:eventsStartDate وeventEndDate) لعنصر ما.في المثال السابق ، يجب أن يكون هناك عنصر جديد لـ "الحدث" الذي قد يحتوي على سمات startDate و enddate.
• تاريخ العمل والتاريخ والوقت والأرقام (على سبيل المثال.يجب أن تكون التهم والمبلغ والمعدل) عناصر.
• يجب أن تكون العناصر الزمنية غير التجارية مثل آخر تحديث ، تنتهي صلاحيتها.
• يجب أن تكون الأرقام غير التجارية مثل رموز التجزئة والمؤشرات سمات. * استخدم العناصر إذا كان النوع معقدًا.
• استخدم السمات إذا كانت القيمة من النوع البسيط ولا تتكرر.
• يجب أن يكون xml:id وxml:lang من السمات التي تشير إلى مخطط XML
• تفضيل السمات عندما يكون ذلك ممكنًا من الناحية الفنية.

تفضيل السمات هو أنه يوفر ما يلي:

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

أضفت عندما يكون ذلك ممكنا من الناحية الفنية لأن هناك أوقاتًا لا يكون فيها استخدام السمات ممكنًا.على سبيل المثال، اختيارات مجموعة السمات.على سبيل المثال، استخدام (startDate وendDate) xor (startTS وendTS) غير ممكن مع لغة المخطط الحالية

إذا بدأ مخطط XML في السماح بتقييد نموذج المحتوى "الكل" أو توسيعه، فمن المحتمل أن أسقطه

Answer 7

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

XHTML هي أحد المجالات التي يكون للسمات فيها استخدام طبيعي (على سبيل المثال.في الفصل='foo').السمات ليس لها ترتيب وهذا قد يسهل على بعض الأشخاص تطوير الأدوات.من الصعب كتابة سمات OTOH بدون مخطط.أجد أيضًا أن سمات مساحة الاسم (foo:bar = "zork") غالبًا ما تكون أكثر صعوبة في إدارتها في مجموعات الأدوات المختلفة.لكن ألق نظرة على بعض لغات W3C لترى المزيج الشائع.تعد SVG، وXSLT، وXSD، وMathML بعض الأمثلة على اللغات المعروفة، وجميعها تتمتع بكمية كبيرة من السمات والعناصر.حتى أن بعض اللغات تسمح بأكثر من طريقة للقيام بذلك، على سبيل المثال.

<foo title="bar"/>;

أو

<foo>
  <title>bar</title>;
</foo>;

لاحظ أن هذه ليست متكافئة من الناحية النحوية وتتطلب دعمًا واضحًا في أدوات المعالجة)

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

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

Answer 8

في حالة الشك، قبلة - لماذا تخلط السمات والعناصر عندما لا يكون لديك سبب واضح لاستخدام السمات.إذا قررت لاحقًا تعريف XSD، فسيصبح ذلك أكثر نظافة أيضًا.ثم إذا قررت لاحقًا إنشاء بنية فئة من XSD الخاص بك، فسيكون ذلك أسهل أيضًا.

Answer 9

سؤال المليون دولار!

أولاً، لا تقلق كثيرًا بشأن الأداء الآن.ستندهش من السرعة التي سيتمكن بها محلل XML المحسّن من تحليل ملف XML الخاص بك.والأهم من ذلك، ما هو تصميمك للمستقبل:مع تطور XML، كيف ستحافظ على الاقتران غير المحكم وقابلية التشغيل البيني؟

وبشكل أكثر واقعية، يمكنك جعل نموذج محتوى العنصر أكثر تعقيدًا ولكن من الصعب توسيع السمة.

Answer 10

استخدم عناصر البيانات والسمات للبيانات التعريفية (بيانات حول بيانات العنصر).

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

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

Answer 11

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

لم يتم تصميم لغة XML لتكون مدمجة، بل لتكون محمولة وقابلة للقراءة من قبل الإنسان.إذا كنت تريد تقليل حجم البيانات أثناء النقل، فاستخدم شيئًا آخر (مثل المخازن المؤقتة لبروتوكول جوجل).

Answer 12

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

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

هناك نقطة أخرى لتعزيز موقفك وهي أنه بينما يتجادل الفريق الآخر حول الأسلوب (حيث ستتعامل معظم أدوات XML مع مستند يحتوي على جميع السمات بنفس السهولة التي تتعامل بها مع مستند #PCDATA بالكامل) فإنك تجادل حول الجوانب العملية.في حين أنه لا يمكن تجاهل الأسلوب تمامًا، إلا أن المزايا التقنية يجب أن تحمل وزنًا أكبر.

Answer 13

كلا الطريقتين لتخزين خصائص الكائن صالحتان تمامًا.يجب عليك الابتعاد عن الاعتبارات العملية.حاول الإجابة على السؤال التالي:

1. ما هو التمثيل الذي يؤدي إلى تحليل/إنشاء البيانات بشكل أسرع؟
2. ما هو التمثيل الذي يؤدي إلى نقل البيانات بشكل أسرع؟

3. هل سهولة القراءة مهمة؟

   ...

Answer 14

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

مثلا أفضّل .....

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
         <person name="Rory" surname="Becker" age="30" />
        <person name="Travis" surname="Illig" age="32" />
        <person name="Scott" surname="Hanselman" age="34" />
    </people>
</data>

...بدلاً من....

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
        <person>
            <name>Rory</name>
            <surname>Becker</surname>
            <age>30</age>
        </person>
        <person>
            <name>Travis</name>
            <surname>Illig</surname>
            <age>32</age>
        </person>
        <person>
            <name>Scott</name>
            <surname>Hanselman</surname>
            <age>34</age>
        </person>
    </people>
</data>

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

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
        <person name="Rory" surname="Becker" age="30" >
            <comment>A programmer whose interested in all sorts of misc stuff. His Blog can be found at http://rorybecker.blogspot.com and he's on twitter as @RoryBecker</comment>
        </person>
        <person name="Travis" surname="Illig" age="32" >
            <comment>A cool guy for who has helped me out with all sorts of SVn information</comment>
        </person>
        <person name="Scott" surname="Hanselman" age="34" >
            <comment>Scott works for MS and has a great podcast available at http://www.hanselminutes.com </comment>
        </person>
    </people>
</data>

Answer 15

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

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

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

Answer 16

مجرد تصحيحين لبعض المعلومات السيئة:

@ جون بالينجر:يمكن أن تحتوي السمات على أي بيانات شخصية.< > & " ' يجب الهروب إلى <>&"و '، على التوالى.إذا كنت تستخدم مكتبة XML، فسوف تعتني بذلك نيابةً عنك.

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

@فينستر:يمكن أن تحتوي السمات على عناصر متعددة مفصولة بمسافات في حالة IDS أو NAMES، والتي قد تتضمن أرقامًا.Nitpicky، ولكن هذا يمكن أن يؤدي في نهاية المطاف إلى توفير المساحة.

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

Answer 17

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

على سبيل المثال، ينتمي النص غير الترميزي دائمًا إلى السمات.دائماً.

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

مخطط XML المكتوب بهذه الطريقة موجز.

كلما أرى حالات مثل <car><make>Ford</make><color>Red</color></car>, أعتقد في نفسي "يا إلهي، هل اعتقد المؤلف أنه ستكون هناك عناصر فرعية داخل عنصر التصنيع؟" <car make="Ford" color="Red" /> هو أكثر قابلية للقراءة بشكل ملحوظ، وليس هناك شك حول كيفية التعامل مع المسافات البيضاء وما إلى ذلك.

نظرًا لقواعد التعامل مع المسافات البيضاء فقط، أعتقد أن هذا كان القصد الواضح لمصممي XML.

Answer 18

وهذا واضح جدًا في HTML حيث يمكن رؤية الاختلافات في السمات والعلامات بوضوح:

1. جميع البيانات بين العلامات
2. يتم استخدام السمات لوصف هذه البيانات (على سبيل المثال.التنسيقات)

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

=> يجب أن تكون معظم البيانات بين العلامات.

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

<customer format="">
     <name></name>
     ...
</customer>

ويمكن للمرء أن يقول أيضًا:"استخدم السمات لوصف العلامة، واستخدم العلامات لتوفير البيانات نفسها."

Answer 19

وأنا أتفق مع فينستر.ابتعد عن الصفات إن استطعت.تعتبر العناصر صديقة للتطور وأكثر قابلية للتشغيل المتبادل بين مجموعات أدوات خدمة الويب.لن تجد أبدًا مجموعات الأدوات هذه التي تقوم بتسلسل رسائل الطلب/الاستجابة الخاصة بك باستخدام السمات.وهذا أمر منطقي أيضًا نظرًا لأن رسائلنا عبارة عن بيانات (وليست بيانات وصفية) لمجموعة أدوات خدمة الويب.

Answer 20

يمكن أن يصبح من الصعب إدارة السمات بسهولة بمرور الوقت، ثق بي.أنا دائما أبقى بعيدا عنهم شخصيا.العناصر أكثر وضوحًا وقابلة للقراءة/الاستخدام من قبل كل من المحللين والمستخدمين.

المرة الوحيدة التي استخدمتها فيها كانت لتحديد امتداد الملف لعنوان URL للأصل:

<image type="gif">wank.jpg</image> ...etc etc

أعتقد أنه إذا كنت تعرف 100%، فلن تحتاج السمة إلى توسيع، ويمكنك استخدامها، ولكن كم مرة تعرف ذلك.

<image>
  <url>wank.jpg</url>
  <fileType>gif</fileType>
</image>