Езикът 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 схема, която някога съм виждал, Получава формата на файла за конфигурация за автоматично осигуряване за 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.
Източник: www.habr.com