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 схемасы, Polycom IP телефония телефондары үшін автоматты қамтамасыз ету конфигурациясының файл пішімін алады. Мұндай файлдар XML сұрау файлдарын TFTP арқылы жүктеп алуды талап етеді, ол... Жалпы, мына бір файлдан үзінді:
<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