तत्व नामों पर केस कन्वेंशन?

120

XML में तत्व आवरण पर कोई औपचारिक सिफारिशें हैं?

मुझे पता है कि एक्सएचटीएमएल लोअरकेस एलिमेंट नाम का उपयोग करता है (एचटीएमएल के विपरीत जो कैनोपिक रूप से अपरकेस का उपयोग करता है लेकिन मामला असंवेदनशील है।)

लेकिन मैं जेनेरिक सामग्री के लिए एक्सएमएल के बारे में बात कर रहा हूं।

लोअरकेस:

<customer> 
   <accountnumber>619</accountnumber>
   <name>Shelby Lake</name>
</customer>

टेढ़े मेढ़े संयुक्त शब्द:

<customer> 
   <accountNumber>619</accountNumber>
   <name>Shelby Lake</name>
</customer>

PascalCase:

<Customer> 
   <AccountNumber>619</AccountNumber>
   <Name>Shelby Lake</Name>
</Customer>

अपरकेस:

<CUSTOMER> 
   <ACCOUNTNUMBER>619</ACCOUNTNUMBER>
   <NAME>Shelby Lake</NAME>
</CUSTOMER>

नोट: मैं राय के बजाय उद्धृत दिशानिर्देशों की तलाश कर रहा हूं। लेकिन सबसे ज्यादा वोट वाले मत को एक दिशानिर्देश माना जा सकता है।

xml case-sensitive

— इयान बॉयड
स्रोत

1

के संभावित डुप्लिकेट वहाँ XML तत्वों के लिए एक मानक नामकरण परंपरा है?

— तुलसी बॉर्क

88

W3C से उत्पन्न अधिकांश XML मानक हाइफ़न के साथ निचले मामले का उपयोग करते हैं।

एक्सएमएल को प्लेटफॉर्म न्यूट्रल डॉक्यूमेंट के लिए एक प्रारूप के रूप में देखने के बीच एक दार्शनिक भेद है, जिसे डब्ल्यू 3 सी मानक प्रोत्साहित करने की कोशिश करते हैं, और एक्सएएमएल जैसी भाषाएं जो एक्सएमएल को एक प्लेटफॉर्म विशिष्ट ऑब्जेक्ट ग्राफ के क्रमांकन के रूप में देखती हैं।

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

यदि आप हैं, तो आप XHTML, XSLT, SVG, XProc, RelaxNG और बाकी के साथ फिट होना चाहते हैं।

— पीट किरखम
स्रोत

7

तो क्या इसका मतलब है कि हाइफ़न के साथ निचला मामला अनुशंसित है या नहीं?

— वॉरफॉक्स

9

@WarFox मुझे नहीं लगता कि किसी ने आधिकारिक सिफारिश की है। IME, इंटरऑपरेबिलिटी के लिए जो प्रारूप w3c से आते हैं, वे हाइफ़न शैली में होते हैं; प्रारूप जो Microsoft से आते हैं और कुछ अन्य लोगों के कार्यान्वयन के लिए कसकर जोड़े जाते हैं और कार्यान्वयन के लिए उपयोग की जाने वाली भाषा में वस्तुओं के नामों के लिए सम्मेलन। यदि आप XML को डिकॉउप सिस्टम में उपयोग कर रहे हैं, तो अपने एक्सएमएल को उस सिस्टम के एक घटक की भाषा शैली में युग्मित न करें, जो आपको वस्तुओं के बजाय संदेशों के संदर्भ में सोचने के लिए मजबूर कर सकता है, और इसलिए मैं कम मामले और हाइफ़न शैली की सिफारिश करूंगा।

— पीट किर्कम

5

ध्यान दें कि XSLT में 'लोअरकेस विथ हाइफ़न' में कुछ समस्याएं हैं। विशेष रूप से एक नोड को भ्रमित करना आसान है, कहते हैं, 'वर्ष-से-उम्र' एक सूत्र के साथ 'वर्ष - आयु' (उदाहरण के लिए वर्ष से घटाना)

— रिचर्ड केनार्ड

3

@RichardKennard क्या यह भ्रम केवल मानव स्तर पर ही संभव है? Xslt के लिए ऑपरेटर के आसपास आवश्यक रिक्त स्थान (?) एक स्पष्ट और स्पष्ट अंतर प्रदान करते हैं, सही?

— कार्ल कीनिंगर ने

1

@KarlKieninger यह सच है, लेकिन मानव स्तर पर भ्रम एक महत्वपूर्ण चिंता है, IMHO। नीचे मेरा विस्तारित जवाब देखें।

— रिचर्ड केनार्ड

64

ऐसा नहीं है कि यह मायने रखता है, लेकिन मैं हमेशा तत्वों के लिए PascalCase और विशेषताओं के लिए camelCase के लिए आंशिक रहा हूं:

<Root>
  <ParentElement attributeId="1">
    <ChildElement attributeName="foo" />
  </ParentElement>
</Root>

— मेट्रो स्मर्फ
स्रोत

31

कोई औपचारिक सिफारिश नहीं है।

चूंकि XML को दस्तावेजों को रखने और असमान प्रणालियों के बीच सूचनाओं के आदान-प्रदान के दोहरे उद्देश्यों के साथ डिजाइन किया गया था , इसलिए इसका उपयोग करने वाले अनुप्रयोगों का मिलान करने में सक्षम होने के लिए इसे डिजाइन किया गया था ।

तो .Net XML प्रॉपर कैशिंग (गवाह XAML) का उपयोग करने के लिए जाता है, जबकि अन्य XML कैमलकास्टिंग, पायथन_कैंशन, डॉट.नामिंग, और यहां तक कि कॉबोल-कन्वेंशन का उपयोग करेगा। W3C को लोअर-केस-के साथ-डैश-काफी-ए-बिट (जैसे XSLT) या justlowercasewordssmodedtt जैसे (जैसे MathML) लगता है।

मुझे सभी निचले मामले पसंद हैं और कोई अंडरस्कोर नहीं है, क्योंकि इसका मतलब है कि [शिफ्ट] कुंजी का कम उपयोग, और मेरी उंगलियां थोड़ी आलसी हैं। :)

— lavinio
स्रोत

2

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

25

मेट्रो स्मर्फ के जवाब में जोड़ने के लिए।

राष्ट्रीय सूचना विनिमय मॉडल (NIEM: http://en.wikipedia.org/wiki/National_Information_Exchange_Model ) का उपयोग करने के लिए कहते हैं:

तत्वों के लिए ऊपरी कैमसेलकेस (पास्कलकेस)।
(निचला) विशेषताओं के लिए कैमलकेस।

जब आप कुछ मानक के अनुरूप देखना चाहते हैं तो NIEM एक अच्छे विकल्प के लिए बनाता है।

— कोएर्ट वैन क्लेफ
स्रोत

1

यहाँ NIEM दस्तावेज़ है जहाँ वे विशेषताओं और तत्वों के नामकरण सम्मेलनों का वर्णन करते हैं: niem.gov/documentsdb/Documents/Technical/NIEM-NDR-1-3.pdf

— e1.1624

मुझे पता है कि यह पुराना है, लेकिन उपरोक्त लिंक टूट गया है, लेकिन यह लिंक तत्वों / Attrubute के लिए NIEM सम्मेलन के बारे में अद्यतन जानकारी है: संदर्भ.

— niem.gov/niem/specification/naming-and-design.rules/…

13

ऊपर मेरी टिप्पणी पर विस्तार करने के लिए : XSLT में 'लोअरकेस विद हाइफ़न' के उपयोग में कुछ समस्याएं हैं। विशेष रूप से, एक नोड को भ्रमित करना आसान है, कहते हैं, 'वर्ष-से-आयु' एक सूत्र 'वर्ष - आयु' के साथ (जैसे वर्ष से उम्र घटाना)।

जैसा कि @KarlKieninger बताते हैं, यह केवल मानव स्तर पर एक समस्या है और XSLT पार्सर के लिए नहीं। हालाँकि, यह अक्सर एक त्रुटि उत्पन्न नहीं करेगा , 'लोअरकेस विद हाइफ़न' का उपयोग करते हुए मानक के रूप में, परेशानी के लिए पूछ रहा है, IMHO।

कुछ प्रासंगिक उदाहरण:

<a>1</a><b>1</b>
<xsl:value-of select="a+b"/>
outputs 2, as expected

<a>1</a><b>1</b>
<xsl:value-of select="a-b"/>
DOES NOT ERROR, BUT OUTPUTS NOTHING AT ALL

उपरोक्त कोड में, आपको घटाव ऑपरेटर से पहले कम से कम एक स्थान रखना चाहिए, लेकिन इसके अलावा ऑपरेटर के लिए ऐसी कोई आवश्यकता नहीं है।

<a-b>1</a-b><c>1</c>
<xsl:value-of select="a-b -c"/>
outputs 0, as expected

लेकिन ध्यान दें कि उपरोक्त पढ़ना कितना भ्रमित है!

<a>1</a><a-b>3</a-b><b>2</b>
<xsl:value-of select="a-b"/>
outputs 3

<a>1</a><a-b>3</a-b><b>2</b>
<xsl:value-of select="a -b"/>
outputs -1

एकल स्थान की मौजूदगी से ऊपर का आउटपुट बदल जाता है, लेकिन न तो संस्करण में कोई त्रुटि है।

— रिचर्ड केनेर्ड
स्रोत

3

बेच दिया। इसके अतिरिक्त MS .NET कोड जनरेशन टूल (xsd.exe) डेसरीएलाइज़ेशन क्लासेस बनाते समय केवल हाइफ़न को छोड़ देगा। इसलिए इसके बजाय अगर "अल्फा-बीटा" जैसे गुण आपको "अल्फाबेटा" मिलते हैं। इतना ही नहीं नाम बिल्कुल अनुवाद नहीं, वे पढ़ने के लिए कठिन हैं। और अगर आपको MS SQL हाइफ़न के साथ xml बनाने की आवश्यकता है तो वहां भी दर्द होता है। एमएस विशिष्ट सामान एक मानक तय नहीं करना चाहिए, लेकिन यह व्यापक उपयोग में है कि मुझे लगता है कि इसे एक विचार के रूप में गिना जा सकता है। और यह मुझे अंडरस्कोर सीमांकित निचले मामले या मिश्रित मामले की ओर ले जाता है।

— कार्ल कीनिंगर

1

ऐसा लगता है कि XSD.exe अब अधिकांश गुणों के लिए एक XmlElementAttribute जोड़ता है, और यदि कोई हाइफ़न है तो यह स्पष्ट रूप से पहले पैरामीटर के रूप में ElementName स्ट्रिंग जोड़ता है ताकि यह स्पष्ट हो जाए। मैंने जो समस्या पाई है, वह यह है कि आपके .NET पुस्तकालयों के आधार पर, यह बात नहीं हो सकती है - तत्व अभी भी कुछ सिस्टम पर डिसेरलाइज़ नहीं करेगा। यह Win201 पर VS2012 में काम करता है, लेकिन 2008 के सर्वर पर EXE के रूप में नहीं चल रहा है।

— डेविड स्टोफर

13

कई मानकों में उपयोग किए गए कुछ उदाहरण नियमों के लिए UN / CEFACT XML नामकरण और डिज़ाइन नियम तकनीकी विनिर्देश संस्करण 3.0 पृष्ठ 23 देखें।

विशेषण (संस्करण 3.0 के पृष्ठ 23 से 17 दिसंबर 2009 तक):

LowerCamelCase (LCC) नामकरण विशेषताओं के लिए उपयोग किया जाना चाहिए।
UpperCamelCase (UCC) का नामकरण तत्वों और प्रकारों के लिए किया जाना चाहिए।
तत्व, विशेषता और प्रकार के नाम एकवचन रूप में होने चाहिए जब तक कि अवधारणा स्वयं बहुवचन न हो।

( अन्य लिंक, स्वीडिश साइट )

— oluies
स्रोत

2

-1: आपका लिंक टूट गया है - शायद यह एक आंतरिक URL है? कृपया इसे ठीक करें, और मैं डाउनवोट हटा दूंगा।

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

3

हालांकि निश्चित रूप से दिलचस्प है, इस विशिष्ट खंड / पृष्ठ पर उद्धृत दस्तावेज़ XML स्कीमा के लिए नियम स्थापित करता है , न कि इस स्कीमा का पालन करने वाले पार्सर / xml दस्तावेज़। ये दो अलग-अलग चीजें हैं।

— श्रीसीसी १

किसी के लिए यह सोचकर कि लोअरकेमसेलकैसे और अपरकैमेलकैसे के बीच क्या अंतर है: mySettingName, लोअरमेन्सेलकैसे (जो लोअरकेमसेल कैस को कॉल करने में होशियार हो सकता है) का एक उदाहरण है, और MySettingName, अपरकेससेलकेस का एक उदाहरण है।

— जिनीले

12

Google की शैली मार्गदर्शिका सभी तत्वों के नाम के साथ-साथ विशेषता नामों के लिए भी (शायद जनादेश) ऊंट की सिफारिश करती है।

— kencordero
स्रोत

4

XML आवरण के लिए मूल इरादा हाइफ़न के साथ कम मामला था। यह संवेदनशील है और आपको उस सम्मेलन का पालन करने की आवश्यकता नहीं है - इसलिए आप जो चाहें कर सकते हैं। मेरे पास कोई उद्धरण नहीं है, क्षमा करें।

— एडम लुटेर
स्रोत

1

मैं यह नहीं कहूंगा कि HTML "कैनोनिकली" अपरकेस का उपयोग करता है। मुझे लगता है कि मूल रूप से अपरकेस का उपयोग HTML को सामग्री से अधिक आसानी से अलग करने के लिए किया गया था। आजकल सिंटैक्स हाइलाइटिंग के साथ, यह आवश्यक नहीं है।

यदि आवश्यक हो (तेज टाइप करने के लिए भी), मैं डैश के साथ लोअरकेस की ओर जाता हूं। XML में मिक्सिंग केस मेरे लिए गलत लगता है।

— DisgruntledGoat
स्रोत

HTML केस-अज्ञेयवादी है। यह वही XML / XHTML नहीं है।

-2

ऊंट केस को मेरा वोट मिला।

उदाहरण के रूप में उद्धृत किया गया है कि शायद यह सवाल उन लोगों का है जो हवाला देते हैं।

— AnthonyWJones
स्रोत