XML विशेषता बनाम XML तत्व

Question

काम के दौरान हमें किसी अन्य ऑफ़लाइन एप्लिकेशन को डेटा पास करने के लिए 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 दस्तावेज़ की संरचना डिज़ाइन करते समय आपको यह कैसे तय करना चाहिए कि किसी विशेषता या तत्व का उपयोग कब किया जाए?

Comments

मुझे यह वास्तव में अच्छा संसाधन लगा: ibm.com/developerworks/xml/library/x-eleatt.html

— लॉरेन्स होल्स्ट

के लिए +1 "... बहस के बारे में था क्या वास्तव में मेटा डेटा था।"

— रोक

कृपया हाइफ़न के साथ लोअरकेस टैग नामों पर ध्यान दें: stackoverflow.com/questions/1074447/…

— बेन '

Answer 1

मैं अंगूठे के इस नियम का उपयोग करता हूं:

1. विशेषता एक ऐसी चीज है जो स्व-निहित है, अर्थात, एक रंग, एक आईडी, एक नाम।
2. एक तत्व एक ऐसी चीज है जो अपने स्वयं के गुण रखता है या हो सकता है जिसमें अन्य तत्व शामिल हैं।

तो तुम्हारा करीबी है। मैंने कुछ ऐसा किया होता:

EDIT : नीचे दिए गए फीडबैक के आधार पर मूल उदाहरण को अपडेट करें ।

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

Comments

मैं कुछ उत्तरों के माध्यम से पढ़ता हूं और कुछ ऐसा है जिस पर जोर नहीं दिया जाता है, मेरा अनुभव यह है कि यदि आप एक "विशेषता" में डेटा रखते हैं और अचानक आपके पास एक या </ XML दस्तावेज़ है, तो मुझे लगता है कि मुझे लगता है कि पांच ascii आकर्षण हैं (>,) <, &;; ",") जो इसे मार देगा। यदि यह विशेष चरित्र एक तत्व में था, तो आप बस इस डेटा के आसपास कुछ सीडीएटीए जोड़ सकते हैं। मैं कहूंगा, केवल तभी विशेषताओं का उपयोग करें जब आप 100% जानते हैं कि कौन से मूल्य डालने जा रहे हैं। वहाँ, उदाहरण के लिए, एक पूर्णांक या एक तिथि, शायद कुछ भी जो कंप्यूटर द्वारा उत्पन्न किया गया है। यदि बारकोड एक मानव द्वारा उत्पन्न किया गया था, तो यह एक विशेषता नहीं होनी चाहिए।

— जॉन बॉलिंगर

वास्तव में पार्टी के लिए देर हो चुकी है, लेकिन विशेष ASCII चार तर्क गलत है - यही है कि भागने के लिए है, दोनों विशेषताओं और पाठ डेटा के लिए।

— माइक्राहटन

@donroby - क्षमा करें, यह संवाद करने में मेरी गलती होगी। भागने से मेरा मतलब XML एन्कोडिंग है। '<' = & lt; इत्यादि मुझे वर्णों के आधार पर एक विशेषता या तत्व के बीच तय करना अजीब लगता है जो सामग्री के अर्थ के बजाय सामग्री बनाते हैं।

— micahtan

@donroby: यह गलत है। का प्रतिस्थापन पाठ <है <, जो एक चरित्र संदर्भ है, एक इकाई संदर्भ नहीं है। <विशेषताओं में ठीक है। देखें: w3.org/TR/REC-xml/#sec-predefined-ent

— porges

@ जॉन: यदि यह एक समस्या है, तो आपके टूलचिन में कुछ है जो वैध XML का उत्पादन नहीं कर रहा है। मुझे नहीं लगता कि यह विशेषताओं या तत्वों के बीच चयन करने का एक कारण है। (इसके अलावा, आप उपयोगकर्ता इनपुट के आसपास "सिर्फ CDATA टैग जोड़ नहीं सकते" क्योंकि इसमें कुछ भी हो सकता है ]]>!)

— जुरा

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

Comments

सबसे पहले बात गलत है, देखें: w3.org/TR/xmlschema-2/#derivation-by-list

— porges

मैं कहूंगा कि पहला बिंदु सही है और listइस समस्या का आंशिक समाधान है। एक ही नाम के साथ कई गुण नहीं हो सकते। listविशेषता के साथ अभी भी केवल एक ही मूल्य है, जो कुछ डेटाटाइप्स की व्हाट्सएप से अलग सूची है। पृथक्करण वर्ण तय किए जाते हैं, इसलिए आपके पास एकाधिक मान नहीं हो सकते हैं यदि वांछित डेटाटाइप का एक भी मान व्हॉट्सएप हो सकता है। यह एक "पता" विशेषता में उदाहरण के लिए कई पते होने की संभावना को नियंत्रित करता है।

— जस्सो

'प्रोग्राम कोड द्वारा हेरफेर करने के लिए विशेषताएँ अधिक कठिन हैं' - उस से सहमत नहीं हो सकते। वास्तव में मैंने इसके विपरीत पाया है। यह वास्तव में किसी भी तरह से अंतर करने के लिए पर्याप्त नहीं है।

— पॉल अलेक्जेंडर

मैं यह भी कहना चाहूंगा कि एक्सटीडी-स्कीमा, स्कैमेट्रॉन और रिलैक्स, एट के साथ डीटीडी के खिलाफ मान्यता वास्तव में प्रासंगिक नहीं है। अल। सभी बहुत अधिक शक्तिशाली प्रदान करते हैं और कुछ मामलों में XML दस्तावेजों को मान्य करने के अधिक सहज तरीके। इसके अलावा, W3Schools किसी भी चीज़ के लिए एक बहुत ही खराब संदर्भ है

Answer 3

"एक्सएमएल" का अर्थ "एक्सटेन्सिबल मार्कअप लैंग्वेज" है। एक मार्कअप भाषा का अर्थ है कि डेटा पाठ है, संरचना या स्वरूपण के बारे में मेटाडेटा के साथ चिह्नित है ।

एक्सएचटीएमएल एक्सएमएल का एक उदाहरण है जिस तरह से इसका उपयोग किया गया था:

<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>

बिंदु यह है कि जब तक आप पत्थर में संरचना को ठीक करने के लिए किसी नाम स्थान के साथ किसी तरह के एक्सएसडी या डीटीडी का निर्माण नहीं करते हैं, तो आप अपने विकल्पों को खुला छोड़ते हुए सबसे अच्छे तरीके से सेवा कर सकते हैं।

IMO XML अपने सबसे उपयोगी है जब इसे उपयोग किए बिना मौजूदा कोड को तोड़ने के बिना फ्लेक्स किया जा सकता है।

Comments

"बारकोड" पर अच्छा बिंदु, मैंने अपना उदाहरण दिया और निश्चित रूप से इसे अपने तत्व में तोड़ दिया होगा। XSD / DTD पर भी अच्छी बात है।

— चक

Answer 6

मैं अपने स्कीमा डिज़ाइन में निम्नलिखित दिशानिर्देशों का उपयोग विशेषताओं बनाम तत्वों के संबंध में करता हूं:

• लंबे चलने वाले पाठ के लिए तत्वों का उपयोग करें (आमतौर पर स्ट्रिंग या सामान्यीकृत प्रकार के)
• यदि किसी तत्व के लिए दो मान (जैसे eventStartDate और eventEndDate) का समूहन है, तो किसी विशेषता का उपयोग न करें। पिछले उदाहरण में, "ईवेंट" के लिए एक नया तत्व होना चाहिए जिसमें स्टार्टडेट और एंडडेट विशेषताएँ हो सकती हैं।
• व्यावसायिक तिथि, दिनांक समय और संख्या (जैसे मायने रखता है, राशि और दर) तत्व होने चाहिए।
• अंतिम अद्यतन जैसे गैर-व्यावसायिक समय तत्व, समय सीमा समाप्त हो जाना चाहिए।
• गैर-व्यावसायिक संख्याएँ जैसे कि हैश कोड और सूचकांक गुण होना चाहिए। * तत्वों का उपयोग करें यदि प्रकार जटिल होगा।
• विशेषताओं का उपयोग करें यदि मान एक सरल प्रकार है और दोहराता नहीं है।
• xml: id और xml: lang XML स्कीमा को संदर्भित करने वाले गुण होने चाहिए
• तकनीकी रूप से संभव होने पर विशेषताओं को प्राथमिकता दें।

विशेषताओं के लिए वरीयता यह निम्नलिखित है:

• अद्वितीय (विशेषता कई बार प्रकट नहीं हो सकती)
• आदेश कोई फर्क नहीं पड़ता
• उपरोक्त गुण अंतर्निहित हैं (यह कुछ ऐसा है जो "सभी" सामग्री मॉडल वर्तमान स्कीमा भाषा में समर्थन नहीं करता है)
• बोनस वे कम क्रिया हैं और कम बैंडविड्थ का उपयोग करते हैं, लेकिन यह वास्तव में तत्वों पर विशेषताओं को पसंद करने का एक कारण नहीं है।

मैंने जोड़ा जब तकनीकी रूप से संभव है क्योंकि ऐसे समय हैं जहां विशेषताओं का उपयोग संभव नहीं है। उदाहरण के लिए, विशेषता सेट विकल्प। उदाहरण के लिए, वर्तमान स्कीमा भाषा के साथ xor (स्टार्ट और एंडडेट) का उपयोग करें (शुरू और अंत करें) संभव नहीं है

यदि XML स्कीमा "सभी" सामग्री मॉडल को प्रतिबंधित या विस्तारित करने की अनुमति देना शुरू कर देती है तो मैं शायद इसे छोड़ दूंगा

Answer 7

संदेह होने पर, KISS - क्यों गुण और तत्वों मिश्रण आप उपयोग विशेषताओं के लिए एक स्पष्ट कारण नहीं है जब। यदि आप बाद में एक एक्सएसडी को परिभाषित करने का निर्णय लेते हैं, तो यह क्लीनर के रूप में अच्छी तरह से समाप्त हो जाएगा। फिर अगर आप बाद में भी अपने एक्सएसडी से एक वर्ग संरचना तैयार करने का निर्णय लेते हैं, तो यह सरल भी होगा।

Answer 8

इस प्रश्न का कोई सार्वभौमिक उत्तर नहीं है (मैं डब्ल्यू 3 सी कल्पना के निर्माण में भारी रूप से शामिल था)। XML का उपयोग कई उद्देश्यों के लिए किया जा सकता है - पाठ जैसे दस्तावेज़, डेटा और घोषणात्मक कोड तीन सबसे आम हैं। मैं इसे एक डेटा मॉडल के रूप में भी उपयोग करता हूं। इन अनुप्रयोगों के ऐसे पहलू हैं जहाँ विशेषताएँ अधिक सामान्य हैं और अन्य जहाँ बाल तत्व अधिक प्राकृतिक हैं। विभिन्न उपकरणों की विशेषताएं भी हैं जो उन्हें उपयोग करना आसान या कठिन बना देती हैं।

एक्सएचटीएमएल एक ऐसा क्षेत्र है जहां विशेषताओं का प्राकृतिक उपयोग होता है (जैसे कक्षा = 'फू')। विशेषताओं के पास कोई आदेश नहीं है और इससे कुछ लोगों के लिए उपकरण विकसित करना आसान हो सकता है। OTOH विशेषताएँ स्कीमा के बिना टाइप करने के लिए कठिन हैं। मुझे नामांकित विशेषताएँ भी मिलती हैं (फ़ू: बार = "ज़ोर्क") अक्सर विभिन्न टूलसेट में प्रबंधन करना कठिन होता है। लेकिन मिश्रण को देखने के लिए W3C की कुछ भाषाओं पर एक नज़र डालें जो आम है। SVG, XSLT, XSD, MathML प्रसिद्ध भाषाओं के कुछ उदाहरण हैं और सभी में विशेषताओं और तत्वों की प्रचुर आपूर्ति है। कुछ भाषाएं भी इसे करने के लिए अधिक-से-एक तरह से अनुमति देती हैं, जैसे

<foo title="bar"/>;

या

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

ध्यान दें कि ये समान रूप से समान नहीं हैं और प्रसंस्करण साधनों में स्पष्ट समर्थन की आवश्यकता है)

मेरी सलाह होगी कि अपने आवेदन के निकटतम क्षेत्र में सामान्य अभ्यास पर एक नज़र डालें और यह भी विचार करें कि आप कौन से टूलसेट लागू करना चाहते हैं।

अंत में सुनिश्चित करें कि आप नामस्थान को विशेषताओं से अलग करते हैं। कुछ XML सिस्टम (जैसे Linq) एपीआई में विशेषताओं के रूप में नामस्थान का प्रतिनिधित्व करते हैं। IMO यह बदसूरत और संभावित भ्रामक है।

Answer 9

अन्य लोगों ने कवर किया है कि तत्वों से विशेषताओं के बीच अंतर कैसे किया जाए लेकिन अधिक सामान्य दृष्टिकोण से सब कुछ विशेषताओं में डाल दिया क्योंकि यह परिणामी XML को छोटा बनाता है।

एक्सएमएल को कॉम्पैक्ट नहीं, बल्कि पोर्टेबल और मानव पठनीय बनाया जा सकता है। यदि आप पारगमन में डेटा के आकार को कम करना चाहते हैं तो कुछ और का उपयोग करें (जैसे कि Google के प्रोटोकॉल बफ़र्स )।

Comments

छोटा XML पाठ अधिक मानव पठनीय है क्योंकि यह छोटा है!

— नशव

Answer 10

मिलियन डॉलर का सवाल!

सबसे पहले, अब प्रदर्शन के बारे में बहुत चिंता न करें। आप इस बात से चकित होंगे कि एक अनुकूलित xml पार्सर आपके xml के माध्यम से कितनी जल्दी चीर देगा। इससे भी महत्वपूर्ण बात यह है कि भविष्य के लिए आपका डिजाइन क्या है: जैसा कि एक्सएमएल विकसित होता है, आप ढीले युग्मन और अंतर को कैसे बनाए रखेंगे?

अधिक संक्षेप में, आप किसी तत्व के सामग्री मॉडल को अधिक जटिल बना सकते हैं, लेकिन एक विशेषता का विस्तार करना कठिन है।

Answer 11

ऑब्जेक्ट के गुणों को संग्रहीत करने के लिए दोनों तरीके पूरी तरह से मान्य हैं। आपको व्यावहारिक विचारों से प्रस्थान करना चाहिए। निम्नलिखित प्रश्न का उत्तर देने का प्रयास करें:

1. कौन सा प्रतिनिधित्व तेज डेटा पार्सिंग \ पीढ़ी की ओर जाता है?

2. कौन सा प्रतिनिधित्व तेजी से डेटा हस्तांतरण की ओर जाता है?

3. पठनीयता मायने रखती है?

   ...

Answer 12

मेटा डेटा के लिए डेटा और विशेषताओं के लिए तत्वों का उपयोग करें (तत्व के डेटा के बारे में डेटा)।

यदि कोई तत्व आपके चयनित स्ट्रिंग्स में एक विधेय के रूप में दिखाई दे रहा है, तो आपके पास एक अच्छा संकेत है कि यह एक विशेषता होना चाहिए। इसी तरह यदि एक विशेषता कभी भी एक विधेय के रूप में उपयोग नहीं की जाती है, तो शायद यह उपयोगी मेटा डेटा नहीं है।

याद रखें कि XML को मशीन पठनीय माना जाता है न कि मानव पठनीय और बड़े दस्तावेज़ों के लिए XML बहुत अच्छी तरह से संपीड़ित करता है।

Answer 13

यह या तो यकीनन सही है, लेकिन आपके सहकर्मी इस मायने में सही हैं कि एक्सएमएल का उपयोग वास्तविक डेटा के आसपास "मार्कअप" या मेटा-डेटा के लिए किया जाना चाहिए। अपने हिस्से के लिए, आप सही हैं कि कभी-कभी यह तय करना मुश्किल होता है कि XML में आपके डोमेन की मॉडलिंग करते समय मेटा-डेटा और डेटा के बीच की रेखा कहाँ है। व्यवहार में, मैं जो कुछ भी करता हूं वह दिखावा है कि मार्कअप में कुछ भी छिपा हुआ है, और केवल मार्कअप के बाहर का डेटा पढ़ने योग्य है। क्या दस्तावेज़ उस तरह से कुछ समझ में आता है?

XML कुख्यात भारी है। परिवहन और भंडारण के लिए, संपीड़न की अत्यधिक अनुशंसा की जाती है यदि आप प्रसंस्करण शक्ति का खर्च उठा सकते हैं। XML अच्छी तरह से संपीड़ित करता है, कभी-कभी अच्छी तरह से इसकी पुनरावृत्ति के कारण। मेरे पास बड़ी फाइलें हैं जो उनके मूल आकार के 5% से कम हैं।

अपनी स्थिति को बढ़ाने के लिए एक और बिंदु यह है कि जब दूसरी टीम शैली के बारे में बहस कर रही है (उस में अधिकांश XML उपकरण एक सभी-विशेषता दस्तावेज़ को आसानी से सभी-# PCDATA दस्तावेज़ के रूप में संभाल लेंगे) आप व्यावहारिकता का तर्क दे रहे हैं। जबकि शैली को पूरी तरह से नजरअंदाज नहीं किया जा सकता है, तकनीकी गुणों को अधिक वजन उठाना चाहिए।

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 वर्णों के अंदर का प्रतिनिधित्व नहीं करता है या कई उद्धरण या अन्य वर्ण शामिल हैं जो भागने की आवश्यकता है तो मैं कहूंगा कि तत्वों को तोड़ने का समय है ... संभवतः सीडीटा ब्लॉकों के साथ।

<?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>

Comments

यह फ्लैट गलत है मुझे डर है - आपको W3C दिशानिर्देशों का पालन करना चाहिए: w3schools.com/DTD/dtd_el_vs_attr.asp - XML ​​को पठनीयता पर या इसे "कॉम्पैक्ट" बनाने पर नहीं बनाया जाना चाहिए - बल्कि उद्देश्य के लिए सही ढंग से या विशेषताओं का उपयोग करना चाहिए। जिसके लिए उन्हें डिजाइन किया गया था।

— विदर्भ

मुझे क्षमा करें, लेकिन यह भ्रामक है। W3schools पृष्ठ W3C दिशानिर्देश नहीं है। W3C XML सिफारिश (जिसमें मैं एक भागीदार था) तत्वों और विशेषताओं को उपयोगकर्ताओं की आवश्यकताओं और शैलियों के अनुसार उपयोग करने की अनुमति देता है।

— pet.m.murray.rust

Answer 15

हमारी कड़ी मेहनत की वस्तु अभिविन्यास अंतर्ज्ञान का लाभ उठाने के बारे में कैसे? मुझे आमतौर पर लगता है कि यह सोचना सीधा है कि कौन सी वस्तु है और कौन सी वस्तु का गुण है या किस वस्तु का जिक्र है।

जो भी सहज रूप से समझ में आता है कि वस्तुएं तत्वों के रूप में फिट होंगी। इसकी विशेषताएँ (या गुण) इन तत्वों की विशेषता xml या बाल तत्व में विशेषता के साथ होगी।

मुझे लगता है कि उदाहरण के लिए आसान मामलों की तरह वस्तु अभिविन्यास सादृश्य ठीक यह पता लगाने के लिए काम करता है कि कौन सा तत्व है और कौन सा तत्व की विशेषता है।

Answer 16

कुछ गलत जानकारी के लिए सुधारों की एक जोड़ी:

@ जॉन बॉलिंगर: विशेषताओं में कोई भी चरित्र डेटा हो सकता है। <> & "'को क्रमशः & lt; & gt; & amp; & quot; और & apos; से बचना होगा। यदि आप XML लाइब्रेरी का उपयोग करते हैं, तो यह आपके लिए ध्यान रखेगा।

नर्क, एक विशेषता में बाइनरी डेटा हो सकता है जैसे कि एक छवि, यदि आप वास्तव में चाहते हैं, तो बस बेस 64-एन्कोडिंग द्वारा और इसे डेटा बनाकर: URL।

@feenster: विशेषताओं में IDS या NAMES के मामले में स्थान-अलग-अलग कई आइटम हो सकते हैं, जिनमें संख्याएँ शामिल होंगी। Nitpicky, लेकिन इससे अंतरिक्ष को बचाया जा सकता है।

विशेषताओं का उपयोग करके XML को JSON के साथ प्रतिस्पर्धात्मक रख सकते हैं। फैट मार्कअप देखें : एक समय में फैट मार्कअप मिथ को एक कैलोरी ट्रिम करना ।

Comments

सिर्फ आईडी या नाम नहीं। वे किसी भी चीज़ के बारे में अंतरिक्ष से अलग सूची बना सकते हैं।

— जॉन सॉन्डर्स

@JohnSaunders IDS या NAMES विशिष्ट DTD प्रकार हैं (XML स्कीमा भी, मुझे लगता है), अधिकांश XML प्रोसेसर द्वारा निम्न स्तर पर समर्थित हैं। यदि XML लाइब्रेरीज़ के बजाय एप्लिकेशन लेयर द्वारा संभाला जाता है, तो किसी भी तरह का कैरेक्टर डेटा काम करता है (अलग मान या जो भी हो)।

— briary

व्यक्तिगत रूप से, सिर्फ इसलिए कि आप का मतलब यह नहीं है कि आपको चाहिए।

— लंकिमार्ट

@Lankymart जैसा कि मैंने कहा, मैं सिर्फ कुछ गलत जानकारी को सही कर रहा था (जो किसी कारण से उच्च स्कोर कर रहा था)। बाइनरी डेटा आमतौर पर XML में बिल्कुल भी नहीं होता है।

— बैरिअरी

Answer 17

मैं हमेशा इस तरह की चर्चाओं के परिणामों से हैरान हूं। मेरे लिए यह तय करने के लिए एक बहुत ही सरल नियम है कि डेटा एक विशेषता के रूप में है या सामग्री के रूप में और यह कि क्या डेटा में नेविगेट करने योग्य उप-संरचना है।

इसलिए उदाहरण के लिए, गैर-मार्कअप पाठ हमेशा विशेषताओं में होता है। हमेशा।

सूचियाँ उप-संरचना या सामग्री में हैं। पाठ जो समय के साथ शामिल हो सकते हैं उनमें एम्बेडेड संरचित उप-सामग्री शामिल है। (मेरे अनुभव में यह अपेक्षाकृत कम है - मार्कअप के साथ पाठ - डेटा भंडारण या विनिमय के लिए एक्सएमएल का उपयोग करते समय।)

XML स्कीमा इस तरह लिखा संक्षिप्त है।

जब भी मुझे इस तरह के मामले दिखाई देते हैं <car><make>Ford</make><color>Red</color></car>, तो मुझे लगता है कि "लेखक ने सोचा था कि मेक एलिमेंट में सब-एलिमेंट्स होने वाले हैं?" <car make="Ford" color="Red" />काफी अधिक पठनीय है, इस बारे में कोई सवाल नहीं है कि व्हाट्सएप को कैसे संभाला जाएगा आदि।

दिए गए नियमों को देखते हुए सिर्फ व्हाट्सएप को देखते हुए, मेरा मानना ​​है कि यह XML डिजाइनरों का स्पष्ट इरादा था।

Comments

कुछ स्पष्टीकरणों में से एक मैं पढ़ सकता हूं। पता नहीं, यह एक अच्छा विचार है या नहीं ... लेकिन कम से कम मुझे बात समझ में आ रही है;)

— थूफ़िर

Answer 18

यह HTML में बहुत स्पष्ट है जहां विशेषताओं और मार्कअप के अंतर को स्पष्ट रूप से देखा जा सकता है:

1. सभी डेटा मार्कअप के बीच है
2. विशेषताएँ इस डेटा को चिह्नित करने के लिए उपयोग की जाती हैं (उदाहरण स्वरूप)

यदि आपके पास XML के रूप में शुद्ध डेटा है, तो कम स्पष्ट अंतर है। डेटा मार्कअप या विशेषताओं के बीच खड़ा हो सकता है।

=> अधिकांश डेटा मार्कअप के बीच में होना चाहिए।

यदि आप यहां विशेषताओं का उपयोग करना चाहते हैं: आप डेटा को दो श्रेणियों में विभाजित कर सकते हैं: डेटा और "मेटा डेटा", जहां मेटा डेटा रिकॉर्ड का हिस्सा नहीं है, आप प्रस्तुत करना चाहते हैं, लेकिन "प्रारूप संस्करण", "बनाई गई तारीख" जैसी चीजें , आदि।

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

कोई यह भी कह सकता है: "टैग को चिह्नित करने के लिए विशेषताओं का उपयोग करें, स्वयं डेटा प्रदान करने के लिए टैग का उपयोग करें।"

Answer 19

मैं फेनस्टर से सहमत हूं। यदि आप कर सकते हैं तो विशेषताओं से दूर रहें। तत्व वेब सेवा टूलकिट के बीच विकास के अनुकूल और अधिक अंतर हैं। आप कभी भी इन टूलकिट को विशेषताओं का उपयोग करके आपके अनुरोध / प्रतिक्रिया संदेशों को क्रमबद्ध नहीं कर पाएंगे। यह भी समझ में आता है क्योंकि हमारे संदेश वेब सेवा टूलकिट के लिए डेटा (मेटाडेटा नहीं) हैं।

Answer 20

विशेषताएँ आसानी से मुश्किल हो सकती हैं समय के साथ मुझ पर भरोसा करें। मैं हमेशा उनसे व्यक्तिगत रूप से दूर रहता हूं। तत्व दोनों पार्सर और उपयोगकर्ताओं द्वारा अधिक स्पष्ट और पठनीय / प्रयोग करने योग्य हैं।

जब भी मैंने कभी उनका उपयोग किया है तो एसेट यूआरएल के फ़ाइल एक्सटेंशन को परिभाषित करना था:

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

मुझे लगता है कि यदि आप जानते हैं कि 100% विशेषता को विस्तारित करने की आवश्यकता नहीं होगी तो आप उनका उपयोग कर सकते हैं, लेकिन आप कितनी बार जानते हैं।

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