Theory
sponsors file ને break કરે છે
fest committee sponsor data ને send કરે છે, અને teammate તેને events.xml માં આ રીતે appends કરે છે:
<events> ... </events>
<sponsors> ... </sponsors>
બે tidy lists, બંને perfectly well-formed અંદર. parser આખી file ને reject કરે છે anyway.
તેનો second attempt એક tag નું નામ બદલીને <Event> કરે છે style માટે, તેને </event> સાથે close કરે છે. ફરીથી rejected.
બે rules, બંને structural, બંને unforgiving: એક root, અને case matters.
Theory
એક parcel માટે એક envelope
courier એ parcel ને accept કરે છે exactly એક outer envelope સાથે. 2 sealed envelopes ને counter પર મૂકો કોઈ wrapper વગર તેમની આસપાસ અને "it" ને send કરવા માંગો: clerk પૂછે છે, કયું એક IS parcel?
root element એ single outer envelope છે: દરેક scrap of data તેની અંદર travel કરે છે. બે top-level elements = 2 envelopes અને કોઈ parcel નહીં: parser, clerk જેમ, ambiguity ને refuse કરે છે.
Theory
root element rule
દરેક XML document પાસે exactly one root element હોય છે (જેને document element પણ કહેવાય છે) જે બાકીના બધા elements ને contain કરે છે.
<events>દરેક<event>ને wrap કરે છે તેને satisfy કરે છે<events>...</events><sponsors>...</sponsors>top level પર violate કરે છે: 2 roots- declaration count નથી કરતું: તે instruction છે, element નહીં, તેથી તે legally root ની ઉપર sits કરે છે
sponsor data માટે fix: એક wider envelope. નવું root <festdata> જે બંને <events> અને <sponsors> ને contain કરે છે તે single-root shape ને restore કરે છે.
Practical
બે roots (rejected) vs એક root (accepted)
<!-- REJECTED: બે top-level elements -->
<?xml version="1.0"?>
<events>
<event><name>Garba Night</name></event>
</events>
<sponsors>
<sponsor>Surat Textiles</sponsor>
</sponsors>
<!-- ACCEPTED: એક root બધું wrap કરે છે -->
<?xml version="1.0"?>
<festdata>
<events>
<event><name>Garba Night</name></event>
</events>
<sponsors>
<sponsor>Surat Textiles</sponsor>
</sponsors>
</festdata>
Theory
Case sensitivity, everywhere
XML names case-sensitive છે, કોઈ exceptions વગર:
<event>,<Event>અને<EVENT>એ 3 different elements છે- start tag ને end tag દ્વારા close કરવું પડે જે identical case નું હોય:
<Name>...</name>એ mismatch error છે - attribute names પણ same law ને follow કરે છે: id અને ID એ different attributes છે
HTML એ તમને 20 વર્ષ સુધી <BODY> લખવા દીધું અને </body> સાથે close કરવા દીધું; તે reflex અહીં bug generator છે. professional defence એ naming convention છે: project માટે all-lowercase (અથવા camelCase) ને pick કરો અને ક્યારેય deviate ન કરો.
Quiz
document માં <events>...</events> છે પછી <sponsors>...</sponsors>, બંને top level પર, બંને internally perfect. XML parser શું કરે છે?
- બંને ને Reads: XML multiple top-level sections ને allow કરે છે
- document ને Rejects કરે છે: તેની પાસે 2 root elements છે exactly 1 ને બદલે
- <events> ને Reads અને <sponsors> ને silently ignores કરે છે
- તેમને એક implicit root માં automatically Merges કરે છે
Show the answer
document ને Rejects કરે છે: તેની પાસે 2 root elements છે exactly 1 ને બદલે
એક root એ absolute છે: parser આખી file ને refuse કરે છે, however clean દરેક section હોય: આ precisely teammate નું bug છે hook થી. Option C એ mercy ને describe કરે છે જે parsers extend નથી કરતા; XML rejection all-or-nothing છે, ક્યારેય partial નહીં. Option D એ શું HTML ના forgiving engines improvise કરી શકે છે, અને તે expectation ને unlearn કરવું એ XML શીખવાનો અડધો ભાગ છે. repair હંમેશા same envelope trick છે: એક wider root (<festdata>) ને invent કરો અને બંને sections ને અંદર move કરો.
Think first
શા માટે so strict? design ને Argue કરો
HTML browsers errors માં guess કરે છે અને web survive કરે છે. tap કરતા પહેલાં: શા માટે XML parsers guess કરવાને બદલે refuse કરે છે? Think કરો કે કોણ દરેક format ને READ કરે છે.
Show the answer
HTML નો reader એ human છે browser દ્વારા: wrong guess એ slightly crooked page ને cost કરે છે, અને human cope કરે છે. XML નો reader usually બીજું program હોય છે: FestConnect નું app જે events.xml ને parse કરે છે, bank જે payment file ને parse કરે છે. guessing parser એ silently WRONG data ને read કરી શકે છે (કયું envelope? કયું <event>?), અને machines crooked ને notice નથી કરતા. first violation પર loudly refusing એટલે errors development માં surface થાય છે, corrupted data તરીકે production માં નહીં. Exam phrasing: strict well-formedness XML ને machine-to-machine data exchange માટે reliable બનાવે છે.
Watch out
2 habits જે HTML veterans ને trip કરે છે
Decorative capitalisation: <Event> ને એક file માં type કરવું અને <event> ને બીજી માં કારણ કે બંને "look fine". lowercase ને pick કરો, હંમેશા, everywhere: convention memory ને beat કરે છે.
top level પર Appending: new data ને closing root tag પછી paste કરવું (sponsor bug). new sections root ની અંદર જાય છે, અથવા root ને wider rename કરવામાં આવે છે. અને remember કરો કે એક legal thing root ની ઉપર: declaration, જે element નથી.
Theory
બે rules, એક mental model
બંને rules same master ને serve કરે છે: parser એ document ને ONE tree તરીકે walk કરી શકવું જોઈએ કોઈ ambiguity વગર: એક trunk (root), branches જે exactly match થાય છે (case-identical tags). tree image ને hold કરો; તે return થાય છે જ્યારે jQuery HTML ના tree ને walk કરે છે Unit 2 માં અને જ્યારે readyState તમને responseXML ને hands કરે છે Unit 4 માં. next lesson document ના 2 sections ને formally names કરે છે: prolog અને document element section.
Summary
Key takeaways
- Exactly ONE root element (document element) દરેક બીજા element ને wrap કરે છે.
- બે top-level elements = ill-formed; તેમને new wider root માં wrap કરો instead.
- XML declaration root ની ઉપર legally sits કરે છે: તે instruction છે, element નહીં.
- everywhere case-sensitive: <Event> એ <event> નથી; start અને end tags exactly match થવા જોઈએ.
- case convention (all lowercase) ને pick કરો અને ક્યારેય deviate ન કરો.
- Parsers guess કરવાને બદલે refuse કરે છે: strictness એ શું machine exchange ને safe બનાવે છે.
- Memory hook: એક envelope, matching labels.