XML - дуже популярний та гнучкий формат у наш час. Кожен програміст повинен розуміти його, це просто must have. Багато технологій зав'язані сьогодні активно його використовують, причому сучасні серед них.
Вступ
Здрастуйте, дорогі читачі моєї статті. Відразу хочу сказати, що це лише перша стаття у моєму циклі з трьох статей. Основна мета всього циклу – присвятити кожного читача в XML і дати, якщо не повне роз'яснення та розуміння, то хоча б хороший такий поштовх до нього, пояснивши основні моменти та речі. Весь цикл буде для однієї номінації – «Увага до деталей», а поділ на 3 статті зроблено для того, щоб вміщатися в ліміт символів у постах та розділити велику кількість матеріалу на більш маленькі порції для більшого розуміння. Перша стаття буде присвячена самому XML і що це таке, а також одному із способів складання схеми для XML файлів – DTD. Для початку, хотілося б висловити невелику передмову для тих, хто взагалі ще не знайомий з XML: не треба лякатися. XML не дуже складний і з ним потрібно розібратися будь-якому програмісту, тому що це дуже гнучкий, ефективний і популярний формат файлів на сьогодні для зберігання різноманітної інформації, яку ви тільки захочете. XML використовується в Ant, Maven, Spring. Будь-якому програмісту потрібне знання XML. Тепер, коли ви зібралися силами та мотивацією, давайте приступати до вивчення. Весь матеріал я намагатимуся викласти максимально просто,
XML
Для більш ясного пояснення, правильніше візуалізувати XML прикладом.
HTML і XML схожі синтаксисом, оскільки вони мають спільний батько – SGML. Однак, у HTML є тільки фіксовані теги конкретного стандарту, в той час як у XML ви можете створювати свої власні теги, атрибути і, в цілому, робити все, що захочете, щоб зберігати дані так, як вам буде зручно. По суті, XML файли може прочитати будь-яка людина, яка знає англійську мову. Зобразити цей приклад можна за допомогою дерева. Корінь дерева – Company. Він же - кореневий (рут) елемент, від якого йдуть всі інші елементи. У кожному XML файлі може бути лише один рут елемент. Він повинен оголошуватись після декларації xml файлу (перший рядок у прикладі) і вміщати в собі всі інші елементи. Небагато про декларацію: вона обов'язковата потрібна для ідентифікації документа як XML. Вона має три псевдо-атрибути (спеціальні зумовлені атрибути): version (за стандартом 1.0), encoding (кодування) і standalone (автономність: якщо yes і до документа підключаються зовнішні схеми, буде помилка, за умовчанням - no). Елементи – це сутності, які зберігають дані за допомогою інших елементів та атрибутів. Атрибути– це додаткова інформація про елемент, який вказується під час додавання елемента. Якщо перекласти пояснення на ООП-полі, то можна навести такий приклад: у нас є машина, у кожної машини є характеристики (колір, місткість, марка та інше) – це атрибути, і є сутності, які всередині машини: двері, вікна, двигун кермо - це інші елементи. Зберігати властивості можна як окремими елементами, так і атрибутами в залежності від вашого бажання. Як ні, XML - вкрай гнучкий формат зберігання даних про що-небудь. Після пояснень нам достатньо розібрати приклад вище, щоб усе стало на свої місця. У прикладі ми описали просту структуру компанії: є компанія, яка має ім'я та офіси, а в офісах є співробітники. Елементи Employees і Offices – елементи обгортки – вони служать для того, щоб зібрати в собі елементи одного виду, по суті, з'єднавши їх в одну множину для зручності обробки. На окрему увагу заслуговують floor і room. Це – атрибути офісу (поверх і номер), тобто його властивості. Якби ми мали елемент «картинка», можна було б передавати її розміри. Ви можете помітити, що компанія не має атрибута name, але є елемент name. Просто ви можете описувати структури так, як захочете. Ніхто не зобов'язує вас усі властивості елементів записувати тільки в атрибути, ви можете використовувати просто елементи і записувати всередині них якісь дані. Наприклад, ми можемо записувати ім'я та посаду наших працівників як атрибути: Якби ми мали елемент «картинка», можна було б передавати її розміри. Ви можете помітити, що компанія не має атрибута name, але є елемент name. Просто ви можете описувати структури так, як захочете. Ніхто не зобов'язує вас усі властивості елементів записувати тільки в атрибути, ви можете використовувати просто елементи і записувати всередині них якісь дані. Наприклад, ми можемо записувати ім'я та посаду наших працівників як атрибути: Якби ми мали елемент «картинка», можна було б передавати її розміри. Ви можете помітити, що компанія не має атрибута name, але є елемент name. Просто ви можете описувати структури так, як захочете. Ніхто не зобов'язує вас усі властивості елементів записувати тільки в атрибути, ви можете використовувати просто елементи і записувати всередині них якісь дані. Наприклад, ми можемо записувати ім'я та посаду наших працівників як атрибути:
Як ви бачите, тепер ім'я та посада кожного працівника – це його атрибути. І можна побачити, що всередині сутності (тега) employee нічого немає, всі елементи employee – порожні. Тоді можна зробити employee порожнім елементом – закрити його одразу після оголошення атрибутів. Це робиться досить просто, досить просто поставити слеш:
Як ви можете помітити, закривши порожні елементи, ми зберегли всю цілісність інформації і набагато скоротабо запис, зробивши інформацію стислішою і читабельнішою. Для того, щоб додати коментар (текст, який буде пропускатися при парсингу файлу) до XML, є наступний синтаксис:
<!-- Іван недавно уволился, только неделю отработать должен. Не забудьте потом удалить его из списка.-->
І остання конструкція – це CDATA , означає «символьні дані». Завдяки даній конструкції можна записувати текст, який не буде інтерпретуватися як розмітка XML. Це корисно, якщо всередині файлу XML у вас є сутність, яка зберігає в інформації XML розмітку. Приклад:
Особливість XML в тому, що ви можете розширювати його так, як захочете використовувати свої елементи, свої атрибути і структурувати його за своїм бажанням. Ви можете використовувати для зберігання даних як атрибути, так і елементи (як це було показано на прикладі раніше). Однак потрібно розуміти, що вигадувати свої елементи та атрибути на ходу і як ви захочете ви можете, але що, якщо ви працюватимете на проекті, де інший програміст захоче перенести елемент name в атрибути, а у вас вся логіка програми написана так, щоб name був елементом? Як створити свої власні правила того, які елементи повинні бути, які атрибути у них є й інші речі, щоб можна було проводити валідацію XML файлів і бути впевненим, що правила стануть стандартними у вашому проекті і ніхто їх порушувати не буде? Для того, щоб написати всі правила вашої власної розмітки XML, є спеціальні засоби. Найвідоміші: DTD та XML Schema. У цій статті буде лише про перше.
DTD
DTD створено для того, щоб описувати типи документів. DTD вже старіє і зараз від нього активно відмовляються в XML, проте ще багато XML файлів використовують саме DTD і, загалом, його корисно розуміти. DTD – це технологія валідації XML-документів . DTD оголошує конкретні правила для типу документа: його елементи, які елементи можуть бути всередині елемента, атрибути, обов'язкові вони чи ні, кількість їх повторень, а також сутності (Entity). За аналогією з XML, для більш чіткого пояснення DTD можна візуалізувати прикладом.
<!-- Объявление возможных элементов --><!ELEMENT employee EMPTY><!ELEMENT employees (employee+)><!ELEMENT office (employees)><!ELEMENT offices (office+)><!ELEMENT name (#PCDATA)><!ELEMENT company (name, offices)><!-- Добавление атрибутов для элементов employee и office --><!ATTLIST employee
name CDATA #REQUIRED
job CDATA #REQUIRED
><!ATTLIST office
floor CDATA #REQUIRED
room CDATA #REQUIRED
><!-- Добавление сущностей --><!ENTITY M"Maksim"><!ENTITY I"Ivan"><!ENTITY F"Franklin">
Ось такий простий приклад у нас є. У цьому прикладі ми оголосабо всю нашу ієрархію з прикладу XML: працівник, працівники, офіс, офіси, ім'я, компанія. Для створення DTD файлів служать 3 основні конструкції, щоб описувати будь-які файли XML: ELEMENT (для опису елементів), ATTLIST (для опису атрибутів для елементів) і ENTITY (для підстановки тексту скороченими формами). ELEMENT Для опису елемента. Елементи, які можна використовувати всередині описаного елемента, перераховуються у дужках у вигляді списку. Можна використовувати квантифікатори для вказівки кількості (вони аналогічні квантифікаторам з регулярних виразів): +значить 1+*означає 0+?АБО01Якщо квантифікаторів не було додано, то вважається, що має бути лише один елемент. Якби нам потрібен був один із групи елементів, можна було б написати так:
<!ELEMENT company ((name | offices))>
Тоді вибирався б один із елементів: name або offices, але якби всередині company було відразу два їх, то валідація б не проходила. Також можна помітити, що у employee є слово EMPTY – це означає, що елемент має бути порожнім. Є ще ANY – будь-які елементи. #PCDATA - Текстові дані. ATTLIST Додасть атрибути до елементів. Після ATTLIST слід назва потрібного елемента, а після словник виду «назва атрибута – тип атрибута», а наприкінці можна додати #IMPLIED (не обов'язковий) або #REQUIRED (обов'язковий). CDATA – текстові дані. Є й інші типи, проте всі вони малі. ENTITY ENTITY служить для оголошення скорочень та тексту, який на них підставлятиметься. По суті ми просто зможемо використовувати в XML замість повного тексту просто назву сутності зі знаком & перед і ; після. Наприклад: щоб відрізняти розмітку в HTML і просто символи, ліву кутову скоби часто екранують за допомогою lt; тільки потрібно ще виставити & перед lt. Тоді ми використовуватимемо не розмітку, а просто символ < . Як ви можете бачити, все досить просто: оголошує елементи, пояснюєте, які елементи оголошені елементи здатні містити, додавання атрибутів цим елементам і, за бажанням, можете додати сутності, щоб скорочувати якісь записи. І тут ви мали б запитати: а як використовувати наші правила у нашому XML файлі? Адже ми просто оголосабо правила, але ми не використовували їх у XML.Є два способи використовувати їх у XML: 1. Впровадження - написання DTD правил усередині самого XML файлу, досить просто написати кореневий елемент після ключового слова DOCTYPE і укласти наш DTD файл усередині квадратних дужок.
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE company [<!-- Объявление возможных элементов --><!ELEMENT employee EMPTY><!ELEMENT employees (employee+)><!ELEMENT office (employees)><!ELEMENT offices (office+)><!ELEMENT name (#PCDATA)><!ELEMENT company (name, offices)><!-- Добавление атрибутов для элементов employee и office --><!ATTLIST employee
name CDATA #REQUIRED
job CDATA #REQUIRED
><!ATTLIST office
floor CDATA #REQUIRED
room CDATA #REQUIRED
><!-- Добавление сущностей --><!ENTITY M"Maksim"><!ENTITY I"Ivan"><!ENTITY F"Franklin">]><company><name>IT-Heaven</name><!-- Іван недавно уволился, только неделю отработать должен. Не забудьте потом удалить его из списка.--><offices><office floor="1" room="1"><employees><employee name="&M;" job="Middle Software Developer"/><employee name="&I;" job="Junior Software Developer"/><employee name="&F;" job="Junior Software Developer"/></employees></office><office floor="1" room="2"><employees><employee name="Herald" job="Middle Software Developer"/><employee name="Adam" job="Middle Software Developer"/><employee name="Leroy" job="Junior Software Developer"/></employees></office></offices></company>
2. Імпорт - ми записуємо всі наші правила в окремий DTD файл, після чого в XML файлі використовуємо DOCTYPE-конструкцію з першого способу, тільки замість квадратних дужок потрібно написати SYSTEM і вказати абсолютний або відносний до поточного розташування файлу шлях.
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE company SYSTEM "dtd_example1.dtd"><company><name>IT-Heaven</name><!-- Іван недавно уволился, только неделю отработать должен. Не забудьте потом удалить его из списка.--><offices><office floor="1" room="1"><employees><employee name="&M;" job="Middle Software Developer"/><employee name="&I;" job="Junior Software Developer"/><employee name="&F;" job="Junior Software Developer"/></employees></office><office floor="1" room="2"><employees><employee name="Herald" job="Middle Software Developer"/><employee name="Adam" job="Middle Software Developer"/><employee name="Leroy" job="Junior Software Developer"/></employees></office></offices></company>
Також можна використовувати ключове слово PUBLIC замість SYSTEM, проте воно навряд чи стане вам у пригоді. Якщо цікаво, то почитати про нього (і про SYSTEM теж) можна докладно тут: посилання . Тепер ми не можемо використовувати інші елементи без їхнього оголошення в DTD, а весь XML підпорядковується нашим правилам. Можете спробувати записати цей код IntelliJ IDEA в окремий файл з розширенням .xml і спробувати додати якісь нові елементи або видалити елемент з нашого DTD і помітите, як IDE буде вказувати вам на помилку. Однак, DTD має свої мінуси:
Він має власний синтаксис, відмінний від синтаксису xml.
У DTD немає перевірки типів даних, а містити він може лише рядки.
DTD не має простору імен.
Про проблему власного синтаксису: ви повинні розбиратися у двох синтаксисах відразу: у XML та DTD синтаксисі. Вони різні, і це може змушувати вас плутатися. Так само, через це складніше відстежувати помилки у величезних XML файлух у поєднанні з такими ж DTD схемами. Якщо у вас щось не запрацювало, доводиться перевіряти величезну кількість текстів різних синтаксисів. Це як читати одночасно дві книжки: російською та англійською. І якщо знання в однієї мови у вас гірше, то розуміти текст буде так само складніше. Про проблему перевірки типів даних: атрибути DTD дійсно мають різні типи, але всі вони, по суті своїй, є рядковими уявленнями чогось, списками або посиланнями. Однак, ви не можете вимагати лише числа, і тим більше позитивні чи негативні. А про об'єктні типи можете взагалі забути. Остання проблема буде обговорюватися вже в наступній статті, яка буде присвячена просторам імен та XML схемам, оскільки обговорення її тут безглуздо. Дякую всім за увагу, я зробив велику роботу і продовжую її робити, щоб вчасно закінчити весь цикл статей. По суті, мені залишилося розібратися з XML схемами і вигадати їх пояснення більш ясними словами, щоб закінчити 2-ю статтю. Її половина вже зроблена, тож можете чекати її найближчим часом. Остання стаття буде повністю присвячена роботі з файлуми XML засобами Java. Успіхів усім і успіхів у програмуванні :) Наступна стаття: щоб вчасно закінчити весь цикл статей. По суті, мені залишилося розібратися з XML схемами і вигадати їх пояснення більш ясними словами, щоб закінчити 2-ю статтю. Її половина вже зроблена, тож можете чекати її найближчим часом. Остання стаття буде повністю присвячена роботі з файлуми XML засобами Java. Успіхів усім і успіхів у програмуванні :) Наступна стаття: щоб вчасно закінчити весь цикл статей. По суті, мені залишилося розібратися з XML схемами і вигадати їх пояснення більш ясними словами, щоб закінчити 2-ю статтю. Її половина вже зроблена, тож можете чекати її найближчим часом. Остання стаття буде повністю присвячена роботі з файлуми XML засобами Java. Успіхів усім і успіхів у програмуванні :) Наступна стаття:[Конкурс] Основи XML для Java програміста - Частина 2 з 3
Корінь дерева – Company. Він же - кореневий (рут) елемент, від якого йдуть всі інші елементи. У кожному XML файлі може бути лише один рут елемент. Він повинен оголошуватись після декларації xml файлу (перший рядок у прикладі) і вміщати в собі всі інші елементи. Небагато про декларацію: вона обов'язковата потрібна для ідентифікації документа як XML. Вона має три псевдо-атрибути (спеціальні зумовлені атрибути): version (за стандартом 1.0), encoding (кодування) і standalone (автономність: якщо yes і до документа підключаються зовнішні схеми, буде помилка, за умовчанням - no). Елементи – це сутності, які зберігають дані за допомогою інших елементів та атрибутів. Атрибути– це додаткова інформація про елемент, який вказується під час додавання елемента. Якщо перекласти пояснення на ООП-полі, то можна навести такий приклад: у нас є машина, у кожної машини є характеристики (колір, місткість, марка та інше) – це атрибути, і є сутності, які всередині машини: двері, вікна, двигун кермо - це інші елементи. Зберігати властивості можна як окремими елементами, так і атрибутами в залежності від вашого бажання. Як ні, XML - вкрай гнучкий формат зберігання даних про що-небудь. Після пояснень нам достатньо розібрати приклад вище, щоб усе стало на свої місця. У прикладі ми описали просту структуру компанії: є компанія, яка має ім'я та офіси, а в офісах є співробітники. Елементи Employees і Offices – елементи обгортки – вони служать для того, щоб зібрати в собі елементи одного виду, по суті, з'єднавши їх в одну множину для зручності обробки. На окрему увагу заслуговують floor і room. Це – атрибути офісу (поверх і номер), тобто його властивості. Якби ми мали елемент «картинка», можна було б передавати її розміри. Ви можете помітити, що компанія не має атрибута name, але є елемент name. Просто ви можете описувати структури так, як захочете. Ніхто не зобов'язує вас усі властивості елементів записувати тільки в атрибути, ви можете використовувати просто елементи і записувати всередині них якісь дані. Наприклад, ми можемо записувати ім'я та посаду наших працівників як атрибути: Якби ми мали елемент «картинка», можна було б передавати її розміри. Ви можете помітити, що компанія не має атрибута name, але є елемент name. Просто ви можете описувати структури так, як захочете. Ніхто не зобов'язує вас усі властивості елементів записувати тільки в атрибути, ви можете використовувати просто елементи і записувати всередині них якісь дані. Наприклад, ми можемо записувати ім'я та посаду наших працівників як атрибути: Якби ми мали елемент «картинка», можна було б передавати її розміри. Ви можете помітити, що компанія не має атрибута name, але є елемент name. Просто ви можете описувати структури так, як захочете. Ніхто не зобов'язує вас усі властивості елементів записувати тільки в атрибути, ви можете використовувати просто елементи і записувати всередині них якісь дані. Наприклад, ми можемо записувати ім'я та посаду наших працівників як атрибути:
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ