Мова 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.
Джерело: habr.com