XML മിക്കവാറും എപ്പോഴും ദുരുപയോഗം ചെയ്യപ്പെടുന്നു

XML ഭാഷ 1996 ലാണ് കണ്ടുപിടിച്ചത്. അത് പ്രത്യക്ഷപ്പെട്ടതിന് തൊട്ടുപിന്നാലെ, അതിന്റെ ആപ്ലിക്കേഷന്റെ സാധ്യതകൾ ഇതിനകം തെറ്റിദ്ധരിക്കപ്പെടാൻ തുടങ്ങിയിരുന്നു, മാത്രമല്ല അവർ അത് പൊരുത്തപ്പെടുത്താൻ ശ്രമിക്കുന്ന ഉദ്ദേശ്യങ്ങൾക്കായി, അത് മികച്ച തിരഞ്ഞെടുപ്പായിരുന്നില്ല.

ഞാൻ കണ്ടിട്ടുള്ള XML സ്കീമകളിൽ ഭൂരിഭാഗവും XML-ന്റെ അനുചിതമോ തെറ്റായതോ ആയ ഉപയോഗങ്ങളാണെന്ന് പറയുന്നതിൽ അതിശയോക്തിയില്ല. കൂടാതെ, XML-ന്റെ ഈ ഉപയോഗം XML എന്താണെന്നതിന്റെ അടിസ്ഥാനപരമായ തെറ്റിദ്ധാരണ പ്രകടമാക്കി.

XML ഒരു മാർക്ക്അപ്പ് ഭാഷയാണ്. ഇതൊരു ഡാറ്റ ഫോർമാറ്റ് അല്ല. മിക്ക XML സ്കീമകളും ഈ വ്യത്യാസം വ്യക്തമായി അവഗണിച്ചു, XML-നെ ഒരു ഡാറ്റ ഫോർമാറ്റുമായി ആശയക്കുഴപ്പത്തിലാക്കുന്നു, ഇത് യഥാർത്ഥത്തിൽ ആവശ്യമുള്ള ഡാറ്റ ഫോർമാറ്റായതിനാൽ XML തിരഞ്ഞെടുക്കുന്നതിൽ ഒരു തെറ്റ് സംഭവിക്കുന്നു.

കൂടുതൽ വിശദാംശങ്ങളിലേക്ക് കടക്കാതെ, ഘടനയും മെറ്റാഡാറ്റയും ഉപയോഗിച്ച് ടെക്‌സ്‌റ്റിന്റെ ബ്ലോക്കുകൾ വ്യാഖ്യാനിക്കാൻ XML ഏറ്റവും അനുയോജ്യമാണ്. ടെക്‌സ്‌റ്റിന്റെ ഒരു ബ്ലോക്ക് ഉപയോഗിച്ച് പ്രവർത്തിക്കുക എന്നതല്ല നിങ്ങളുടെ പ്രധാന ലക്ഷ്യം എങ്കിൽ, XML തിരഞ്ഞെടുക്കുന്നത് ന്യായീകരിക്കപ്പെടാൻ സാധ്യതയില്ല.

ഈ വീക്ഷണകോണിൽ നിന്ന്, XML സ്കീമ എത്ര നന്നായി നിർമ്മിച്ചിരിക്കുന്നു എന്ന് പരിശോധിക്കാൻ ഒരു ലളിതമായ മാർഗമുണ്ട്. ഉദ്ദേശിച്ച സ്കീമയിലെ ഒരു പ്രമാണം ഉദാഹരണമായി എടുത്ത് അതിൽ നിന്ന് എല്ലാ ടാഗുകളും ആട്രിബ്യൂട്ടുകളും നീക്കം ചെയ്യാം. അവശേഷിക്കുന്നത് അർത്ഥമാക്കുന്നില്ലെങ്കിൽ (അല്ലെങ്കിൽ ഒരു ശൂന്യമായ വരി അവശേഷിക്കുന്നുണ്ടെങ്കിൽ), ഒന്നുകിൽ നിങ്ങളുടെ സ്കീമ ശരിയായി നിർമ്മിച്ചിട്ടില്ല അല്ലെങ്കിൽ നിങ്ങൾ XML ഉപയോഗിക്കേണ്ടതില്ല.

തെറ്റായി നിർമ്മിച്ച സർക്യൂട്ടുകളുടെ ഏറ്റവും സാധാരണമായ ചില ഉദാഹരണങ്ങൾ ഞാൻ ചുവടെ നൽകും.

<roоt>
  <item name="name" value="John" />
  <item name="city" value="London" />
</roоt>

XML-ൽ ഒരു ലളിതമായ കീ-മൂല്യം നിഘണ്ടു പ്രകടിപ്പിക്കാനുള്ള അടിസ്ഥാനരഹിതവും വിചിത്രവുമായ (വളരെ സാധാരണമാണെങ്കിലും) ശ്രമത്തിന്റെ ഒരു ഉദാഹരണം ഇവിടെ കാണാം. നിങ്ങൾ എല്ലാ ടാഗുകളും ആട്രിബ്യൂട്ടുകളും നീക്കം ചെയ്താൽ, നിങ്ങൾക്ക് ഒരു ശൂന്യമായ വരി അവശേഷിക്കും. അടിസ്ഥാനപരമായി, ഈ പ്രമാണം, അത് എത്ര അസംബന്ധമാണെന്ന് തോന്നിയാലും, ഒരു ശൂന്യമായ വരിയുടെ അർത്ഥപരമായ വ്യാഖ്യാനമാണ്.

<root name="John" city="London" />

കാര്യങ്ങൾ കൂടുതൽ വഷളാക്കാൻ, ഒരു നിഘണ്ടു പ്രകടിപ്പിക്കുന്നതിനുള്ള അതിരുകടന്ന മാർഗമെന്ന നിലയിൽ ശൂന്യമായ സ്‌ട്രിംഗിന്റെ അർത്ഥപരമായ വ്യാഖ്യാനം ഞങ്ങളുടെ പക്കലില്ല - ഇത്തവണ "നിഘണ്ടു" നേരിട്ട് റൂട്ട് എലമെന്റിന്റെ ആട്രിബ്യൂട്ടുകളായി എൻകോഡ് ചെയ്‌തിരിക്കുന്നു. ഇത് ഒരു മൂലകത്തിൽ നൽകിയിരിക്കുന്ന ആട്രിബ്യൂട്ട് പേരുകളുടെ ഗണത്തെ നിർവചിക്കാത്തതും ചലനാത്മകവുമാക്കുന്നു. മാത്രമല്ല, രചയിതാവ് യഥാർത്ഥത്തിൽ പ്രകടിപ്പിക്കാൻ ആഗ്രഹിച്ചത് ഒരു ലളിതമായ കീ-മൂല്യം വാക്യഘടനയാണെന്ന് ഇത് കാണിക്കുന്നു, പകരം XML പ്രയോഗിക്കാനുള്ള തികച്ചും വിചിത്രമായ തീരുമാനം അദ്ദേഹം എടുത്തു, ആട്രിബ്യൂട്ട് വാക്യഘടന ഉപയോഗിക്കുന്നതിന് ഒരു പ്രിഫിക്‌സായി ഒരു ശൂന്യമായ ഘടകം ഉപയോഗിക്കാൻ നിർബന്ധിച്ചു. അത്തരം സ്കീമുകൾ ഞാൻ പലപ്പോഴും കാണാറുണ്ട്.

<roоt>
  <item key="name">John</item>
  <item key="city">London</item>
</roоt>

ഇതൊരു മികച്ച കാര്യമാണ്, എന്നാൽ ഇപ്പോൾ ചില കാരണങ്ങളാൽ കീകൾ മെറ്റാഡാറ്റയാണ്, മൂല്യങ്ങൾ അങ്ങനെയല്ല. നിഘണ്ടുക്കളിൽ വളരെ വിചിത്രമായ ഒരു നോട്ടം. നിങ്ങൾ എല്ലാ ടാഗുകളും ആട്രിബ്യൂട്ടുകളും നീക്കം ചെയ്താൽ, പകുതി വിവരങ്ങൾ നഷ്ടപ്പെടും.

XML-ൽ ശരിയായ നിഘണ്ടു പ്രയോഗം ഇതുപോലെ കാണപ്പെടും:

<roоt>
  <item>
    <key>Name</key>
    <value>John</value>
  </item>
  <item>
    <key>City</key>
    <value>London</value>
  </item>
</roоt>

എന്നാൽ XML എന്നത് ഒരു ഡാറ്റ ഫോർമാറ്റായി ഉപയോഗിക്കാനും പിന്നീട് ഒരു പദാവലി സംഘടിപ്പിക്കാനും ആളുകൾ വിചിത്രമായ തീരുമാനമെടുത്തിട്ടുണ്ടെങ്കിൽ, അവർ ചെയ്യുന്നത് അനുചിതവും സൗകര്യപ്രദവുമല്ലെന്ന് അവർ മനസ്സിലാക്കണം. ഡിസൈനർമാർ അവരുടെ ആപ്ലിക്കേഷനുകൾ സൃഷ്ടിക്കാൻ തെറ്റായി XML തിരഞ്ഞെടുക്കുന്നതും സാധാരണമാണ്. എന്നാൽ പലപ്പോഴും, XML ഇതിന് അനുയോജ്യമല്ല എന്ന വസ്തുത അവഗണിച്ച്, മുകളിൽ വിവരിച്ച ഫോമുകളിലൊന്നിൽ അർത്ഥരഹിതമായി XML ഉപയോഗിക്കുന്നതിലൂടെ അവർ കാര്യങ്ങൾ കൂടുതൽ വഷളാക്കുന്നു.

ഏറ്റവും മോശം XML സ്കീമ? വഴിയിൽ, സമ്മാനം ഞാൻ കണ്ടിട്ടുള്ളതിൽ വച്ച് ഏറ്റവും മോശം XML സ്കീമ, പോളികോം ഐപി ടെലിഫോണി ഫോണുകൾക്കായി ഓട്ടോമാറ്റിക് പ്രൊവിഷനിംഗ് കോൺഫിഗറേഷൻ ഫയൽ ഫോർമാറ്റ് ലഭിക്കുന്നു. അത്തരം ഫയലുകൾക്ക് TFTP വഴി XML അഭ്യർത്ഥന ഫയലുകൾ ഡൗൺലോഡ് ചെയ്യേണ്ടതുണ്ട്, അത്... പൊതുവേ, അത്തരത്തിലുള്ള ഒരു ഫയലിൽ നിന്നുള്ള ഒരു ഉദ്ധരണി ഇതാ:

<softkey
        softkey.feature.directories="0"
        softkey.feature.buddies="0"
        softkey.feature.forward="0"
        softkey.feature.meetnow="0"
        softkey.feature.redial="1"
        softkey.feature.search="1"

        softkey.1.enable="1"
        softkey.1.use.idle="1"
        softkey.1.label="Foo"
        softkey.1.insert="1"
        softkey.1.action="..."

        softkey.2.enable="1"
        softkey.2.use.idle="1"
        softkey.2.label="Bar"
        softkey.2.insert="2"
        softkey.2.action="..." />

ഇത് ആരുടെയെങ്കിലും മോശം തമാശയല്ല. ഇത് എന്റെ കണ്ടുപിടുത്തമല്ല:

• ആട്രിബ്യൂട്ടുകൾ അറ്റാച്ചുചെയ്യുന്നതിനുള്ള ഒരു ഉപസർഗ്ഗമായി ഘടകങ്ങൾ ഉപയോഗിക്കുന്നു, അവയ്ക്ക് ശ്രേണിപരമായ പേരുകളുണ്ട്.
• ഒരു പ്രത്യേക തരം റെക്കോർഡിന്റെ ഒന്നിലധികം സന്ദർഭങ്ങളിൽ നിങ്ങൾക്ക് മൂല്യങ്ങൾ നൽകണമെങ്കിൽ, ഇത് ചെയ്യുന്നതിന് നിങ്ങൾ ആട്രിബ്യൂട്ട് പേരുകൾ ഉപയോഗിക്കണം. സൂചികകൾ ഉള്ളവ.
• കൂടാതെ, ആരംഭിക്കുന്ന ആട്രിബ്യൂട്ടുകൾ softkey., മൂലകങ്ങളിൽ സ്ഥാപിക്കണം <softkey/>, എന്ന് തുടങ്ങുന്ന ആട്രിബ്യൂട്ടുകൾ feature., മൂലകങ്ങളിൽ സ്ഥാപിക്കണം <feature/> മുതലായവ, ഇത് പൂർണ്ണമായും അനാവശ്യവും ഒറ്റനോട്ടത്തിൽ അർത്ഥശൂന്യവുമാണെന്ന് തോന്നുന്നുവെങ്കിലും.
• അവസാനമായി, ഒരു ആട്രിബ്യൂട്ട് നാമത്തിന്റെ ആദ്യ ഘടകം എല്ലായ്പ്പോഴും മൂലകത്തിന്റെ പേരിന് സമാനമാകുമെന്ന് നിങ്ങൾ പ്രതീക്ഷിക്കുന്നുണ്ടെങ്കിൽ - അങ്ങനെയൊന്നുമില്ല! ഉദാഹരണത്തിന്, ആട്രിബ്യൂട്ടുകൾ up. ഘടിപ്പിച്ചിരിക്കണം <userpreferences/>. ഘടകങ്ങളിലേക്ക് ആട്രിബ്യൂട്ട് പേരുകൾ അറ്റാച്ചുചെയ്യുന്ന ക്രമം ഏകപക്ഷീയമാണ്, ഏതാണ്ട് പൂർണ്ണമായും.

പ്രമാണങ്ങൾ അല്ലെങ്കിൽ ഡാറ്റ. ഓരോ തവണയും, XML-ഉം JSON-ഉം താരതമ്യം ചെയ്യാൻ ശ്രമിച്ചുകൊണ്ട് ആരെങ്കിലും തികച്ചും വിചിത്രമായ എന്തെങ്കിലും ചെയ്യുന്നു-അതുവഴി അവർക്കും മനസ്സിലാകുന്നില്ലെന്ന് കാണിക്കുന്നു. XML ഒരു ഡോക്യുമെന്റ് മാർക്ക്അപ്പ് ഭാഷയാണ്. JSON ഒരു ഘടനാപരമായ ഡാറ്റ ഫോർമാറ്റാണ്, അതിനാൽ അവയെ പരസ്പരം താരതമ്യപ്പെടുത്തുന്നത് ചൂടിനെ മൃദുവുമായി താരതമ്യം ചെയ്യാൻ ശ്രമിക്കുന്നത് പോലെയാണ്.

തമ്മിലുള്ള വ്യത്യാസത്തിന്റെ ആശയം രേഖകളും ഡാറ്റയും. XML-ന്റെ അനലോഗ് എന്ന നിലയിൽ, നമുക്ക് ഒരു മെഷീൻ റീഡബിൾ ഡോക്യുമെന്റ് സോപാധികമായി എടുക്കാം. ഇത് മെഷീൻ റീഡബിൾ ആയിരിക്കാൻ ഉദ്ദേശിച്ചുള്ളതാണെങ്കിലും, ഇത് ഡോക്യുമെന്റുകളെ രൂപകമായി സൂചിപ്പിക്കുന്നു, ഈ വീക്ഷണകോണിൽ നിന്ന് യഥാർത്ഥത്തിൽ മെഷീൻ റീഡബിൾ അല്ലാത്ത PDF പ്രമാണങ്ങളുമായി താരതമ്യപ്പെടുത്താവുന്നതാണ്.

ഉദാഹരണത്തിന്, XML-ൽ ഘടകങ്ങളുടെ ക്രമം പ്രധാനമാണ്. എന്നാൽ JSON-ൽ, ഒബ്‌ജക്‌റ്റുകൾക്കുള്ളിലെ കീ-വാല്യൂ ജോഡികളുടെ ക്രമം അർത്ഥശൂന്യവും നിർവചിക്കപ്പെടാത്തതുമാണ്. നിങ്ങൾക്ക് കീ-വാല്യൂ ജോഡികളുടെ ക്രമരഹിതമായ നിഘണ്ടു ലഭിക്കണമെങ്കിൽ, ആ ഫയലിൽ ഘടകങ്ങൾ ദൃശ്യമാകുന്ന യഥാർത്ഥ ക്രമം പ്രശ്നമല്ല. എന്നാൽ ഈ ഡാറ്റയിൽ നിന്ന് നിങ്ങൾക്ക് പല തരത്തിലുള്ള ഡാറ്റ രൂപീകരിക്കാൻ കഴിയും. രേഖകളുടെ, പ്രമാണത്തിൽ ഒരു നിശ്ചിത ക്രമം ഉള്ളതിനാൽ. ഒരു പ്രിന്റൗട്ട് അല്ലെങ്കിൽ PDF ഫയലിൽ നിന്ന് വ്യത്യസ്തമായി, ഭൗതിക അളവുകൾ ഇല്ലെങ്കിലും, കടലാസിലെ ഒരു ഡോക്യുമെന്റിനോട് സാമ്യമുള്ളതാണ് ഇത്.

ശരിയായ XML നിഘണ്ടു പ്രാതിനിധ്യത്തിന്റെ എന്റെ ഉദാഹരണം, JSON പ്രാതിനിധ്യത്തിന് വിരുദ്ധമായി നിഘണ്ടുവിലെ ഘടകങ്ങളുടെ ക്രമം കാണിക്കുന്നു. എനിക്ക് ഈ ഓർഡർ അവഗണിക്കാൻ കഴിയില്ല: ഈ രേഖീയത ഡോക്യുമെന്റ് മോഡലിലും XML ഫോർമാറ്റിലും അന്തർലീനമാണ്. ഈ XML പ്രമാണം വ്യാഖ്യാനിക്കുമ്പോൾ ചിലർ ഓർഡർ അവഗണിക്കാൻ തീരുമാനിച്ചേക്കാം, എന്നാൽ ഇതിനെക്കുറിച്ച് തർക്കിക്കുന്നതിൽ അർത്ഥമില്ല, കാരണം ഈ പ്രശ്നം ഫോർമാറ്റിന്റെ ഒരു ചർച്ചയുടെ പരിധിക്കപ്പുറമാണ്. അതിലുപരിയായി, ഒരു കാസ്‌കേഡിംഗ് സ്റ്റൈൽ ഷീറ്റ് ഘടിപ്പിച്ച് ബ്രൗസറിൽ ഡോക്യുമെന്റ് കാണാവുന്നതാക്കി മാറ്റുകയാണെങ്കിൽ, നിഘണ്ടു ഘടകങ്ങൾ ഒരു നിശ്ചിത ക്രമത്തിലും മറ്റൊന്നിലും ദൃശ്യമാകുന്നത് നിങ്ങൾ കാണും.

മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഒരു നിഘണ്ടു (ഘടനാപരമായ ഡാറ്റയുടെ ഒരു ഭാഗം) ആയി പരിവർത്തനം ചെയ്യാൻ കഴിയും n സാധ്യമായ വിവിധ രേഖകൾ (എക്സ്എംഎൽ, പിഡിഎഫ്, പേപ്പർ മുതലായവയിൽ), എവിടെ n - നിഘണ്ടുവിലെ മൂലകങ്ങളുടെ സാധ്യമായ കോമ്പിനേഷനുകളുടെ എണ്ണം, സാധ്യമായ മറ്റ് വേരിയബിളുകൾ ഞങ്ങൾ ഇതുവരെ പരിഗണിച്ചിട്ടില്ല.

എന്നിരുന്നാലും, നിങ്ങൾക്ക് ഡാറ്റ മാത്രം കൈമാറണമെങ്കിൽ, ഇതിനായി ഒരു മെഷീൻ റീഡബിൾ ഡോക്യുമെന്റ് ഉപയോഗിക്കുന്നത് ഫലപ്രദമാകില്ലെന്നും ഇത് പിന്തുടരുന്നു. ഇത് ഒരു മോഡൽ ഉപയോഗിക്കുന്നു, ഈ സാഹചര്യത്തിൽ അത് അമിതമാണ്; അത് വഴിയിൽ മാത്രമേ ലഭിക്കൂ. കൂടാതെ, ഉറവിട ഡാറ്റ എക്‌സ്‌ട്രാക്‌റ്റുചെയ്യുന്നതിന്, നിങ്ങൾ ഒരു പ്രോഗ്രാം എഴുതേണ്ടതുണ്ട്. ചില ഘട്ടങ്ങളിൽ ഒരു ഡോക്യുമെന്റായി ഫോർമാറ്റ് ചെയ്യപ്പെടാത്ത ഒരു കാര്യത്തിന് XML ഉപയോഗിക്കുന്നതിൽ യാതൊരു അർത്ഥവുമില്ല (പറയുക, CSS അല്ലെങ്കിൽ XSLT അല്ലെങ്കിൽ രണ്ടും ഉപയോഗിക്കുക), കാരണം അങ്ങനെ ചെയ്യുന്നതിനുള്ള പ്രധാന (ഒന്നല്ലെങ്കിൽ) കാരണം അതാണ്. പ്രമാണ മാതൃകയിലേക്ക്.

കൂടാതെ, XML-ൽ സംഖ്യകളുടെ (അല്ലെങ്കിൽ ബൂളിയൻ എക്സ്പ്രഷനുകൾ അല്ലെങ്കിൽ മറ്റ് ഡാറ്റ തരങ്ങൾ) യാതൊരു ആശയവും ഇല്ലാത്തതിനാൽ, ഈ ഫോർമാറ്റിൽ പ്രതിനിധീകരിക്കുന്ന എല്ലാ സംഖ്യകളും ഒരു അധിക വാചകമായി കണക്കാക്കുന്നു. ഡാറ്റ എക്‌സ്‌ട്രാക്‌റ്റുചെയ്യുന്നതിന്, സ്കീമയും പ്രകടിപ്പിക്കുന്ന അനുബന്ധ ഡാറ്റയുമായുള്ള അതിന്റെ ബന്ധവും അറിഞ്ഞിരിക്കണം. സന്ദർഭത്തെ അടിസ്ഥാനമാക്കി, ഒരു പ്രത്യേക ടെക്സ്റ്റ് ഘടകം എപ്പോഴാണ് ഒരു സംഖ്യയെ പ്രതിനിധീകരിക്കുന്നത്, അത് ഒരു സംഖ്യയിലേക്ക് പരിവർത്തനം ചെയ്യേണ്ടത് എപ്പോഴാണ് എന്നും നിങ്ങൾ അറിയേണ്ടതുണ്ട്.

അതിനാൽ, XML പ്രമാണങ്ങളിൽ നിന്ന് ഡാറ്റ എക്‌സ്‌ട്രാക്റ്റുചെയ്യുന്ന പ്രക്രിയ, സ്കാൻ ചെയ്‌ത പ്രമാണങ്ങൾ തിരിച്ചറിയുന്ന പ്രക്രിയയിൽ നിന്ന് വളരെ വ്യത്യസ്തമല്ല, ഉദാഹരണത്തിന്, സംഖ്യാ ഡാറ്റയുടെ നിരവധി പേജുകൾ സൃഷ്ടിക്കുന്ന പട്ടികകൾ. അതെ, തത്വത്തിൽ ഇത് ചെയ്യാൻ കഴിയും, എന്നാൽ മറ്റ് ഓപ്ഷനുകളൊന്നും ഇല്ലാതിരിക്കുമ്പോൾ, അവസാന ആശ്രയമെന്ന നിലയിൽ ഇത് ഏറ്റവും ഒപ്റ്റിമൽ മാർഗമല്ല. ഒരു രേഖാ മാതൃകയിൽ ഉൾച്ചേർക്കാത്ത യഥാർത്ഥ ഡാറ്റയുടെ ഡിജിറ്റൽ പകർപ്പ് കണ്ടെത്തുക എന്നതാണ് ന്യായമായ പരിഹാരം.

അതായത്, XML ബിസിനസ്സിൽ ജനപ്രിയമാണെന്നത് എന്നെ അതിശയിപ്പിക്കുന്നില്ല. ഇതിനുള്ള കാരണം, ഡോക്യുമെന്റ് ഫോർമാറ്റ് (പേപ്പറിൽ) മനസ്സിലാക്കാവുന്നതും ബിസിനസ്സിന് പരിചിതവുമാണ്, മാത്രമല്ല അവർ പരിചിതവും മനസ്സിലാക്കാവുന്നതുമായ ഒരു മോഡൽ ഉപയോഗിക്കുന്നത് തുടരാൻ ആഗ്രഹിക്കുന്നു. അതേ കാരണത്താൽ, ബിസിനസ്സുകളും കൂടുതൽ മെഷീൻ-റീഡബിൾ ഫോർമാറ്റുകൾക്ക് പകരം PDF പ്രമാണങ്ങൾ ഉപയോഗിക്കുന്നു - കാരണം അവ ഇപ്പോഴും ഒരു പ്രത്യേക ഫിസിക്കൽ വലുപ്പമുള്ള ഒരു അച്ചടിച്ച പേജ് എന്ന ആശയവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു. ഒരിക്കലും അച്ചടിക്കാൻ സാധ്യതയില്ലാത്ത പ്രമാണങ്ങൾക്ക് പോലും ഇത് ബാധകമാണ് (ഉദാഹരണത്തിന്, രജിസ്ട്രി ഡോക്യുമെന്റേഷന്റെ 8000 പേജുള്ള PDF). ഈ വീക്ഷണകോണിൽ നിന്ന്, ബിസിനസ്സിൽ എക്സ്എംഎൽ ഉപയോഗിക്കുന്നത് പ്രധാനമായും സ്ക്യൂമോർഫിസത്തിന്റെ പ്രകടനമാണ്. പരിമിതമായ വലുപ്പമുള്ള ഒരു അച്ചടിച്ച പേജിന്റെ രൂപക ആശയം ആളുകൾ മനസ്സിലാക്കുന്നു, അച്ചടിച്ച പ്രമാണങ്ങളെ അടിസ്ഥാനമാക്കി ബിസിനസ്സ് പ്രക്രിയകൾ എങ്ങനെ സൃഷ്ടിക്കാമെന്ന് അവർ മനസ്സിലാക്കുന്നു. അത് നിങ്ങളുടെ ഗൈഡ് ആണെങ്കിൽ, മെഷീൻ റീഡബിൾ ആയ ഫിസിക്കൽ സൈസ് പരിമിതികളില്ലാത്ത ഡോക്യുമെന്റുകൾ - XML ​​ഡോക്യുമെന്റുകൾ - പരിചിതവും സൗകര്യപ്രദവുമായ ഒരു ഡോക്യുമെന്റ് കൗണ്ടർപാർട്ട് ആയിരിക്കുമ്പോൾ തന്നെ നവീകരണത്തെ പ്രതിനിധീകരിക്കുന്നു. ഡാറ്റ അവതരിപ്പിക്കുന്നതിനുള്ള തെറ്റായതും അമിതമായ സ്ക്യൂമോർഫിക് മാർഗമായി തുടരുന്നതിൽ നിന്ന് ഇത് അവരെ തടയുന്നില്ല.

ഇന്നുവരെ, എനിക്ക് അറിയാവുന്ന ഒരേയൊരു XML സ്കീമകൾ XHTML, DocBook എന്നിവയാണ്.

അവലംബം: www.habr.com