🥇XML практически винаги се използва неправилно

XML езикът беше създаден през 1996 година. Почти веднага след като се появи, възможностите за неговото приложение започнаха да се разбират неправилно, и той не представляваше най-добрия избор за целите, за които се опитваха да го адаптират.

Не е преувеличение да се каже, че преобладаващото мнозинство от XML схеми, които съм виждал, представляваха нецелесъобразно или неправилно използване на XML. Освен това, такова приложение на XML свидетелстваше за основно непознаване на това, какво всъщност представлява XML.

XML е език за маркиране. Това не е формат за данни. В повечето XML схеми това разграничение явно не се взимаше под внимание, обърквайки XML с формат за данни, което накрая означаваше грешка в избора на XML, тъй като всъщност е необходим именно формат за данни.

Без да навлизаме в детайли, XML е най-подходящ за анотиране на текстови блокове със структура и метаданни. Ако основната ви задача не е работа с текстов блок, изборът на XML едва ли ще бъде оправдан.

От тази гледна точка съществува прост начин да проверите колко добре е направена XML схемата. Вземете например документ в предвидената схема и премахнете всички тагове и атрибути от него. Ако в това, което е останало, няма смисъл (или ако остава празен ред), то или вашата схема е построена неправилно, или просто не трябваше да използвате XML.

По-долу ще дам няколко от най-често срещаните примери на неправилно построени схеми.

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

Тук виждаме пример за неоправдан и странен (макар и доста разпространен) опит да се изрази с 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

XML почти винаги се прилага неправилно