XML езикът е създаден през 1996 година. Почти веднага след появяването му възможностите за неговото приложение бяха неправилно разбрани и за целите, за които се опитваха да го адаптират, той не беше най-добрият избор.
Не е преувеличение да се каже, че огромното мнозинство от XML схемите, които съм виждал, представляват нецелесъобразно или неправилно използване на XML. Освен това такова прилагане на XML свидетелства за фундаментално непонимание на това, какво всъщност е XML.
XML е език за маркиране. Това не е формат на данни.. В повечето XML схеми това разделение явно не беше отчетено, бъркайки XML с формат на данни, което в крайна сметка означаваше грешка в самия избор на XML, тъй като всъщност беше необходим именно формат на данни.
Без да навлизаме в детайли, XML е най-подходящ за анотиране на текстови блокове със структура и метаданни. Ако основната ви задача не е работа с текстов блок, изборът на XML едва ли ще бъде оправдан.
От тази гледна точка има прост начин да се провери колко добре е изградена XML схемата. Нека вземем примерен документ в предполагаемата схема и да премахнем всички тагове и атрибути от него. Ако в това, което остава, няма смисъл (или ако остава празен ред), то или вашата схема е изградена неправилно, или просто не е трябвало да прилагате XML.
По-долу ще дам няколко от най-често срещаните примери за неправилно изградени схеми.
Тук виждаме пример за неоснователна и странна (макар и доста разпространена) опит да се изрази със XML прост речник "ключ-стойност". Ако премахнем всички тагове и атрибути, остава празен ред. По същество този документ представлява, колкото и абсурдно да звучи, семантична анотация на празен ред.
<root name="John" city="London" />Още по-лошо, тук не просто семантична анотация на празен ред като екстравагантен начин за изразяване на речник – този път „речникът“ е директно кодирано под формата на атрибути на кореновия елемент. Поради това зададеният набор от имена на атрибути на елемента става неопределен и динамичен. Още по-лошо, тук се вижда, че всичко, което авторът всъщност е искал да изрази, е простия синтаксис „ключ-стойност“, но вместо това е взел абсолютно странно решение да приложи XML, принуждавайки да използва единичен празен елемент просто като префикс за синтаксиса на атрибутите. И такива схеми ми попадат много често.
John
LondonТова е вече нещо по-добро, но сега ключовете по някаква причина са метаданни, а стойностите – не. Въпреки че е странен поглед върху речниците. Ако премахнете всички тагове и атрибути, половината информация ще бъде загубена.
Правилното представяне на речника в XML ще изглежда приблизително така:
Name
John
City
LondonНо ако хората са взели странно решение да прилагат XML като формат на данните и след това да подреждат речника с него, те трябва да разбират, че това, което правят, е несъобразително и не удобно. Често проектанти погрешно избират XML за създаване на своите приложения. Но още по-често те влошават ситуацията с безсмислено приложение на XML в една от описаните по-горе форми, игнорирайки факта, че XML просто не е подходящ за това.
Най-лошата XML схема? Между другото, наградата за най-лошата XML схема, която съм виждал, печели форматът на конфигурационен файл за автоматично разпределение на ресурси за IP телефони Polycom. Такива файлове изискват зареждане на 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 — броят на възможните комбинации от елементите в речника, и това е преди да вземем предвид други потенциални променливи.
В същото време от това следва, че ако искате да предадете само данни, използването на машиночитаем документ би било неефективно. Използва се модел, който в този случай е излишен и ще пречи. Освен това, за да извлечете основните данни, ще трябва да напишете програма. Вряд ли има смисъл да използвате XML за нещо, което на даден етап няма да бъде форматирано като документ (да кажем, с помощта на CSS или XSLT, или и двете), тъй като това е основната (ако не единствената) причина да се придържаме към документния модел.
Освен това, тъй като в XML няма понятие за числа (или булеви изрази, или други типове данни), всички числа, представени в този формат, се считат просто за допълнителен текст. За извличане на данни трябва да бъде известна схемата и нейната връзка с съответните данни. Също така, е необходимо да знаете, кога в зависимост от контекста, даден елемент от текста представлява число и трябва да бъде преобразуван в число, и т.н.
По този начин, процесът на извличане на данни от XML документи не се различава особено от процеса на разпознаване на сканирани документи, съдържащи, например, таблици, образуващи множество страници числови данни. Да, възможно е в основата си, но не е най-оптималният подход - освен в крайни случаи, когато няма други опции. Разумно решение е просто да се намери цифрова версия на оригиналните данни, не включени в документационния модел, в който данните са обединени с тяхното конкретно текстово представяне.
Не ме изненадва, че XML е популярен в бизнеса. Причината за това е именно, че форматът на документите (на хартия) е разбираем и познат за бизнеса, и те искат да продължат да използват познатата и ясна модел. По същата причина в бизнеса твърде често се използват документи в PDF вместо по-удобни за машинна обработка формати - защото те все още са привързани към концепцията за печатна страница с определен физически размер. Това важи дори за тези документи, които едва ли някога ще бъдат отпечатани (например, PDF файл на документация на регистър с 8000 страници). От тази гледна точка, използването на XML в бизнеса всъщност е проява на скевоморфизъм. Хората разбират метафоричната идея за печатна страница с ограничен размер и знаят как да създават бизнес процеси въз основа на печатни документи. Ако това е вашият ориентир, документи без ограничен физически размер, които са машинно четими - XML документи - представляват иновация, като същевременно са познат и удобен аналог на документа. Това не пречи на тях да остават неправилен и прекалено скевоморфен начин за представяне на данни.
Към момента единствените известни ми XML схеми, които мога да нарека правилно приложение на този формат, са XHTML и DocBook.
Източник: habr.com
