Theory
Sponsors File को तोड़ देते हैं
Fest committee sponsor data भेजती है, और एक teammate इसे events.xml में इस तरह append करता है:
<events> ... </events>
<sponsors> ... </sponsors>
दो tidy lists, अंदर से दोनों perfectly well-formed। Parser फिर भी पूरी file reject कर देता है।
इसका दूसरा attempt style के लिए एक tag को <Event> rename करता है, इसे </event> से close करते हुए। फिर से rejected।
दो rules, दोनों structural, दोनों unforgiving: एक root, और case matter करता है।
Theory
एक Parcel, एक Envelope
एक courier exactly एक outer envelope वाला parcel accept करता है। Counter पर बिना किसी wrapper के 2 sealed envelopes रखिए और "इसे" भेजने के लिए कहिए: clerk पूछता है, कौन सा IS parcel?
Root element वह single outer envelope है: data का हर scrap इसके अंदर travel करता है। दो top-level elements = 2 envelopes और कोई parcel नहीं: parser, clerk की तरह, ambiguity refuse कर देता है।
Theory
Root Element Rule
हर XML document के पास exactly एक root element है (जिसे document element भी कहते हैं) जो बाकी सारे elements contain करता है।
- हर
<event>को wrap करता<events>इसे satisfy करता है - Top level पर
<events>...</events><sponsors>...</sponsors>इसे violate करता है: 2 roots - Declaration count नहीं होता: यह एक instruction है, element नहीं, तो यह legally root के ऊपर बैठता है
Sponsor data के लिए fix: एक wider envelope। <events> AND <sponsors> दोनों वाला एक नया root <festdata> single-root shape restore करता है।
Practical
दो Roots (Rejected) बनाम एक Root (Accepted)
<!-- REJECTED: two top-level elements -->
<?xml version="1.0"?>
<events>
<event><name>Garba Night</name></event>
</events>
<sponsors>
<sponsor>Surat Textiles</sponsor>
</sponsors>
<!-- ACCEPTED: one root wraps everything -->
<?xml version="1.0"?>
<festdata>
<events>
<event><name>Garba Night</name></event>
</events>
<sponsors>
<sponsor>Surat Textiles</sponsor>
</sponsors>
</festdata>
Theory
Case Sensitivity, हर जगह
XML names case-sensitive हैं, कोई exceptions नहीं:
<event>,<Event>और<EVENT>3 अलग elements हैं- एक start tag को identical case वाले एक end tag से close होना ज़रूरी है:
<Name>...</name>एक mismatch error है - attribute names भी same law follow करते हैं: id और ID अलग attributes हैं
HTML ने आपको 20 साल तक <BODY> लिखने और </body> से close करने दिया; वह reflex यहाँ bug generator है। Professional defence एक naming convention है: एक project के लिए all-lowercase (या camelCase) चुनिए और कभी deviate मत कीजिए।
Quiz
एक document में <events>...</events> के बाद <sponsors>...</sponsors> है, दोनों top level पर, दोनों internally perfect। एक XML parser क्या करता है?
- दोनों पढ़ता है: XML कई top-level sections allow करता है
- Document reject करता है: इसमें exactly 1 के बजाय 2 root elements हैं
- <events> पढ़ता है और चुपचाप <sponsors> ignore करता है
- उन्हें automatically एक implicit root में merge करता है
Show the answer
Document reject करता है: इसमें exactly 1 के बजाय 2 root elements हैं
एक root absolute है: parser पूरी file refuse कर देता है, चाहे हर section कितना भी clean हो: यह exactly hook का teammate वाला bug है। Option C एक mercy describe करता है जो parsers नहीं देते; XML rejection all-or-nothing है, कभी partial नहीं। Option D वह है जो HTML के forgiving engines improvise कर सकते थे, और उस expectation को unlearn करना XML सीखने का आधा हिस्सा है। Repair हमेशा वही envelope trick है: एक wider root invent कीजिए (<festdata>) और दोनों sections को अंदर move कीजिए।
Think first
इतना Strict क्यों? Design Argue कीजिए
HTML browsers errors के through guess करते हैं और web survive करता है। Tap करने से पहले: XML parsers guess करने के बजाय refuse क्यों करते हैं? सोचिए हर format कौन पढ़ता है।
Show the answer
HTML का reader एक browser के ज़रिए एक human है: एक wrong guess एक थोड़ा टेढ़ा page cost करता है, और human cope कर लेता है। XML का reader usually कोई और program है: FestConnect का app events.xml parse करता हुआ, एक bank एक payment file parse करता हुआ। एक guessing parser चुपचाप WRONG data पढ़ सकता है (कौन सा envelope? कौन सा <event>?), और machines crooked नोटिस नहीं करतीं। पहली violation पर loudly refuse करने का मतलब है errors development में surface होते हैं, production में corrupted data की तरह नहीं। Exam phrasing: strict well-formedness XML को machine-to-machine data exchange के लिए reliable बनाती है।
Watch out
2 Habits जो HTML Veterans को Trip कराती हैं
Decorative Capitalisation: एक file में <Event> और दूसरी में <event> type करना क्योंकि दोनों "ठीक लगते हैं"। Lowercase चुनिए, हमेशा, हर जगह: convention memory से बेहतर है।
Top Level पर Append करना: closing root tag के बाद pasted नया data (sponsor bug)। नए sections root के INSIDE जाते हैं, या root wider नाम दिया जाता है। और root के ऊपर वाली एक legal चीज़ याद रखिए: declaration, जो एक element नहीं है।
Theory
दो Rules, एक Mental Model
दोनों rules एक ही master serve करते हैं: एक parser document को बिना किसी ambiguity के ONE tree की तरह walk कर पाए: एक trunk (root), branches जो exactly match करें (case-identical tags)। Tree image रखिए; यह Unit 2 में jQuery के HTML का tree walk करते समय और Unit 4 में जब readyState आपको responseXML देता है तब वापस आती है। अगला lesson document के 2 sections को formally नाम देता है: prolog और document element section।
Summary
Key takeaways
- Exactly ONE root element (document element) बाकी हर element को wrap करता है।
- Top level पर दो elements = ill-formed; इसके बजाय इन्हें एक नए wider root में wrap कीजिए।
- XML declaration legally root के ऊपर बैठता है: यह एक instruction है, element नहीं।
- Case-sensitive हर जगह: <Event>, <event> नहीं है; start और end tags को exactly match करना ज़रूरी है।
- एक case convention चुनिए (all lowercase) और कभी deviate मत कीजिए।
- Parsers guess करने के बजाय refuse करते हैं: strictness ही machine exchange को safe बनाती है।
- Memory hook: एक envelope, matching labels।