எக்ஸ்எம்எல் எப்போதும் தவறாகப் பயன்படுத்தப்படுகிறது

எக்ஸ்எம்எல் 1996 இல் கண்டுபிடிக்கப்பட்டது. அதன் பயன்பாடுகள் பரவலாக தவறாகப் புரிந்து கொள்ளப்படுவதற்கு முன்பு அது படத்திற்கு வெளியே இருந்தது, மேலும் அது மாற்றியமைக்கப்பட்ட நோக்கங்களுக்கு இது சிறந்த தேர்வாக இருக்கவில்லை.

நான் பார்த்த பெரும்பாலான 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 பல்வேறு சாத்தியமான ஆவணங்கள் (XML வடிவத்தில், PDF, காகிதத்தில், முதலியன), எங்கே n — அகராதியில் உள்ள தனிமங்களின் சாத்தியமான சேர்க்கைகளின் எண்ணிக்கை, மேலும் பிற சாத்தியமான மாறிகளை நாங்கள் இன்னும் கணக்கில் எடுத்துக்கொள்ளவில்லை.

இருப்பினும், நீங்கள் தரவை மட்டும் அனுப்ப விரும்பினால், இயந்திரம் படிக்கக்கூடிய ஆவணத்தைப் பயன்படுத்துவது திறமையற்றது என்பதையும் இது குறிக்கிறது. இது ஒரு மாதிரியைப் பயன்படுத்துகிறது, இது தேவையற்றது மற்றும் வழியில் மட்டுமே வரும். மேலும், மூலத் தரவைப் பிரித்தெடுப்பதற்கு நிரலாக்கம் தேவைப்படுகிறது. ஒரு கட்டத்தில் ஆவணமாக வடிவமைக்கப்படாத எதற்கும் (CSS அல்லது XSLT அல்லது இரண்டையும் பயன்படுத்தி) XML ஐப் பயன்படுத்துவது அர்த்தமற்றது, ஏனெனில் இது ஒரு ஆவண மாதிரியில் ஒட்டிக்கொள்வதற்கான முதன்மை (ஒரே காரணம் அல்ல என்றாலும்) காரணம்.

மேலும், XML இல் எண்கள் (அல்லது பூலியன் வெளிப்பாடுகள் அல்லது பிற தரவு வகைகள்) பற்றிய கருத்து இல்லாததால், இந்த வடிவத்தில் குறிப்பிடப்படும் அனைத்து எண்களும் கூடுதல் உரையாக மட்டுமே கருதப்படுகின்றன. தரவைப் பிரித்தெடுக்க, ஸ்கீமா மற்றும் வெளிப்படுத்தப்படும் தொடர்புடைய தரவுகளுடனான அதன் உறவு அறியப்பட வேண்டும். சூழலின் அடிப்படையில், ஒரு குறிப்பிட்ட உரை உறுப்பு எப்போது ஒரு எண்ணைக் குறிக்கிறது மற்றும் ஒன்றாக மாற்றப்பட வேண்டும் என்பதை அறிந்து கொள்வதும் அவசியம்.

எனவே, XML ஆவணங்களிலிருந்து தரவைப் பிரித்தெடுக்கும் செயல்முறை, பல பக்க எண் தரவுகளைக் கொண்ட அட்டவணைகள் போன்ற ஸ்கேன் செய்யப்பட்ட ஆவணங்களைக் கொண்ட அங்கீகார செயல்முறையிலிருந்து மிகவும் வேறுபட்டதல்ல. கொள்கையளவில் இது சாத்தியம் என்றாலும், இது மிகவும் உகந்த அணுகுமுறை அல்ல - ஒருவேளை, வேறு எந்த விருப்பங்களும் இல்லாதபோது, ​​இது ஒரு கடைசி முயற்சியாக இருந்தால் தவிர. ஒரு நியாயமான தீர்வாக, தரவை அதன் குறிப்பிட்ட உரை பிரதிநிதித்துவத்துடன் இணைக்கும் ஆவண மாதிரியில் உட்பொதிக்கப்படாமல், அசல் தரவின் டிஜிட்டல் நகலை வெறுமனே கண்டுபிடிப்பது இருக்கும்.

இருப்பினும், XML வணிகத்தில் பிரபலமாக இருப்பதில் எனக்கு எந்த ஆச்சரியமும் இல்லை. ஆவண வடிவம் (காகிதத்தில்) வணிகங்களுக்குப் புரிந்துகொள்ளக்கூடியதாகவும் பரிச்சயமானதாகவும் இருப்பதால் இது துல்லியமாக உள்ளது, மேலும் அவர்கள் இந்த பழக்கமான மற்றும் புரிந்துகொள்ளக்கூடிய மாதிரியைத் தொடர்ந்து பயன்படுத்த விரும்புகிறார்கள். அதே காரணத்திற்காக, வணிகங்களும் பெரும்பாலும் இயந்திரம் படிக்கக்கூடிய வடிவங்களுக்குப் பதிலாக PDF ஆவணங்களைப் பயன்படுத்துகின்றன - ஏனெனில் அவை ஒரு குறிப்பிட்ட இயற்பியல் அளவிலான அச்சிடப்பட்ட பக்கத்தின் கருத்துடன் பிணைக்கப்பட்டுள்ளன. இது ஒருபோதும் அச்சிடப்பட வாய்ப்பில்லாத ஆவணங்களுக்கும் பொருந்தும் (எடுத்துக்காட்டாக, 8000 பக்க பதிவு ஆவணங்களின் PDF கோப்பு). இந்தக் கண்ணோட்டத்தில், வணிகத்தில் XML ஐப் பயன்படுத்துவது அடிப்படையில் ஸ்கீயோமார்பிசத்தின் வெளிப்பாடாகும். வரையறுக்கப்பட்ட அளவிலான அச்சிடப்பட்ட பக்கத்தின் உருவகக் கருத்தை மக்கள் புரிந்துகொள்கிறார்கள், மேலும் அச்சிடப்பட்ட ஆவணங்களின் அடிப்படையில் வணிக செயல்முறைகளை எவ்வாறு உருவாக்குவது என்பதை அவர்கள் புரிந்துகொள்கிறார்கள். இது உங்கள் வழிகாட்டியாக இருந்தால், இயந்திரம் படிக்கக்கூடிய இயற்பியல் அளவு வரம்புகள் இல்லாத ஆவணங்கள் - XML ​​ஆவணங்கள் - புதுமையை பிரதிநிதித்துவப்படுத்துகின்றன, அதே நேரத்தில் ஒரு ஆவணத்திற்குப் பரிச்சயமான மற்றும் வசதியான சமமானவை. இது தரவை வழங்குவதற்கான தவறான மற்றும் அதிகப்படியான ஸ்கீயோமார்பிக் வழியாக இருந்து அவர்களைத் தடுக்காது.

இன்றைய நிலவரப்படி, எனக்குத் தெரிந்த, அந்த வடிவமைப்பின் சரியான பயன்பாடுகளை நான் உண்மையிலேயே அழைக்கக்கூடிய ஒரே XML திட்டங்கள் XHTML மற்றும் DocBook மட்டுமே.

ஆதாரம்: www.habr.com