Розширювана Мова Розмітки (Extensible Markup Language - XML) 1.1 (Друге видання)

1.1 Походження та цілі створення

Ця специфікація, разом з відповідними стандартами (Unicode [Unicode] та ISO / IEC 10646 [ISO/IEC 10646] для символів, Internet RFC 3066 [IETF RFC 3066] міток ідентифікації мови, ISO 639 [ISO 639] за для кодів назв мови, та ISO 3166 [ISO 3166] за для кодів назв країн), надає всю інформацію, необхідну для розуміння XML версії 1.1 і побудови комп'ютерної програми для його обробки.

Ця версія специфікації XML може поширюватися вільно, оскільки всі тексти та юридичні повідомлення залишаються незмінними.

1.2 Термінологія

Термінологія, яка використовується для опису XML документів, визначених в тілі цієї специфікації. Ключові слова ПОВИННІ, НЕ ПОВИННІ, НАЛЕЖИТЬ, РЕКОМЕНДОВАНО, МОЖЕ, і НЕОБОВ'ЯЗКОВО, при підкресленні, повинні тлумачитись, як описано в [IETF RFC 2119]. Крім того, терміни, визначені в наступному списку, використовуються в будівництві цих визначень і при описі дій в XML процесора:

error/помилка

[Визначення: Порушення правил цієї специфікації; результати невизначені. Якщо не вказано інше, недотримання вказівок цієї специфікації вказує на одне з ключових слів MUST, REQUIRED, MUST NOT, SHALL і SHALL NOT, і не є помилкою. Відповідне програмне забезпечення може виявляти і повідомляти про помилку, також оборбляти їх.]

fatal error/фатальна помилка

[Визначення: Таку помилку процесор XML зобов'язаний виявляти і повідомляти про неї програмі. Після виявлення фатальної помилки, процесор може продовжити обробку даних для виявлення інших помилок і повідомлення про них програмі. Щоб мати можливість підтримки обробки та виправлення помилок, процесор може зробити необроблені дані документа (суміш символьних даних і розмітки) доступними програмі. Однак, якщо виявлена фатальна помилка, процесор зобов'язаний не продовжувати нормальну обробку (тобто він зобов'язаний не продовжувати передачу інформацію про символьні дані і логічну структуру документа програмі у звичайний способ).]

at user option/на визначення користувача

[Визначення: Відповідні програми можуть або зобов'язані (залежно від модального дієслова у реченні) вести себе так, як описано; якщо це відбувається, користувачам обов'язково має бути представлений засіб включити або відключити пильнування поведінки.]

validity constraint/обмеження дії

[Визначення: норма, яка застосовується до всіх дійсних XML документів. Порушення обмежень правильності є помилкою; вона зобов'язана, за вибором користувача, видавати повідомлення процесорами XML перевірки.]

well-formedness/обмеження правильного формування

[Визначення: Правило, що застосовується до всіх правильно сформованих документів XML. Порушення обмежень правильного формування є фатальною помилкою.]

match/співпадає

[Визначення: (Для рядків або імен) Два рядки або імені порівнюються як ідентичні. Символи з безліччю можливих уявлень в Unicode (наприклад, символи, що мають попередньовизначену або "база + діакрітіческій знак" форми) співпадають тільки тоді, коли вони мають такі ж самі співпадіння в обох рядках. Приведення регістра не виконується. (Для рядків та правил граматики:) Рядок збігається з граматичним об'єктом, якщо він належить до мови, що генерується цим об'єктом. (Для вмісту і моделей вмісту:) Елемент збігається зі своїм оголошенням, якщо він відповідає за формою опису в обмеженні [VC: Дійсний елемент].]

for compatibility/для сумісності

[Визначення: Позначає пропозицію, що описує властивість XML, увімкнена тільки для того, щоб упевнитися, що XML залишається сумісним з SGML.]

for interoperability/для забезпечення взаємодії

[Визначення: Позначає пропозицію, що описує зобов'язующі рекомендації, включені для того, щоб збільшити шанси того, що документи XML можуть бути оброблені існуючою встановленою базою процесорів SGML, які існували до WebSGML Adaptations Annex /Адаптивного доповнення до ISO 8879.]

1.3 Обгрунтування і список змін у XML 1.1

2.1 Правильно сформовані документи XML

[Визначення: Текстовий об'єкт є правильно сформованим документом XML, якщо:]

1. Взятий в цілому, він збігається з документом, позначеним граматичним об'єктом.

2. Він задовольняє всім обмеженням правильного формування, даними в цій специфікації.

3. Кожен з розбираємих примірників, на які є пряме або непряме посилання в документі, є правильно сформованими.

Документ

Збіг з об'єктом документа передбачає, що:

1. Він містить один або більше елементів.

2. [Визначення: Є тільки один елемент, який називається root, або елемент документа, ніяка частина якого не з'являється у вмісті будь-якого іншого елемента.] Для всіх інших елементів: якщо початкова мітка (тег) знаходиться всередині іншого елемента, то кінцевий тег знаходиться всередині того ж самого елементу. Простіше кажучи, елементи, обмежені початковою і кінцевою мітками (тегами), вкладаються відповідним чином один в інший.

[Визначення: Як наслідок цього, для кожного некорневого елемента C в документі є елемент P в такому документі, що C знаходиться у вмісті елементу P, але не у вмісті будь-якого іншого елемента, який знаходиться у вмісті P. P називається parent/батьком C, а C - child/нащадком P.]

2.2 Символи

[Визначення: Розбираємий екземпляр містить текст, послідовність символів, яка може представляти символьні дані або розмітку.] [Визначення: character/символ це атомарна (первинна) одиниця тексту, як спеціфіціїовано в ISO/IEC 10646 [ISO/IEC 10646] (див. також [ISO/IEC 10646-2000]). Дозволеними символами є символи табуляції, повернення каретки, переведення рядка і всі допустимі символи Unicode і ISO/IEC 10646. Версії цих стандартів, зазначені в A.1 Нормативні посилання, що діяли на момент створення цього документа. Нові символи можуть бути додані до цих стандартів у доповненнях і нових редакціях. Отже, процесори XML зобов'язані приймати будь-які символи в діапазоні, специфицированном для Char. Використання "символів сумісності", як зазначено в розділі 6.8 [Unicode] (див. також D21 в розділі 3.6 [Unicode3]), не рекомендовано.]

Character Range/Діапазон символів

Механізм кодування кодових точок символів всередині бітовий послідовностей може варіюватися від екземпляра до примірника. Всі процесори XML зобов'язані приймати кодування UTF-8 та UTF-16 з Unicode [Unicode]. Механізм позначення того, яка з двох кодувань використовується, і підключення інших кодувань обговорюється пізніше в розділі 4.3.3 Кодування символів примірників.

[#x1-#x8], [#xB-#xC], [#xE-#x1F], [#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDDF], [#x1FFFE-#x1FFFF], [#x2FFFE-#x2FFFF], [#x3FFFE-#x3FFFF], [#x4FFFE-#x4FFFF], [#x5FFFE-#x5FFFF], [#x6FFFE-#x6FFFF], [#x7FFFE-#x7FFFF], [#x8FFFE-#x8FFFF], [#x9FFFE-#x9FFFF], [#xAFFFE-#xAFFFF], [#xBFFFE-#xBFFFF], [#xCFFFE-#xCFFFF], [#xDFFFE-#xDFFFF], [#xEFFFE-#xEFFFF], [#xFFFFE-#xFFFFF], [#x10FFFE-#x10FFFF].

2.3 Загальні синтаксичні конструкції

S (пробіл), складається з одного або декількох порожніх (#x20) символів, повернення каретки, рядока стрічки чи вкладок.

Пробіл

[Визначення: Name/Ім'я це лексична одиниця, що починається буквою або одним із символів пунктуації та триваюча літерами, цифрами, дефісом, символами підкреслення, двокрапкою або full stops, відомими як символи іменування.] Імена, що починаються рядком "xml" або будь-яким рядком, збігається з (('X'|'x') ('M'|'m') ('L'|'l')), зарезервовані для цілей стандартизації в цій або наступних версіях даної специфікації.

У Nmtoken (знаку найменування) є будь-яке поєднання символів імені.

Перший символ в імені повинен бути NameStartChar, а також будь-які інші символи повинні бути NameChars; цей механізм використовується для запобігання іменам, починаючи з Європейського (ASCII) або цифр з основними поєднаннями символів. Практично всі символи дозволені в іменах, за винятком тих, які або знаходяться, або розумно могли бути використані як роздільники. Мета полягає в тому, щоб бути всеосяжним, а не ексклюзивним, так що написання систем поки ще не в кодуванні Unicode можна використовувати для імен XML. Див. Пропозиції за назвами XML для пропозицій щодо створення назв.

Авторам документу рекомендується використовувати імена, які мають сенс слова або поєднання слів у природних мовах, і, щоб уникнути символічних або білих символів в іменах. Зауважимо, що двокрапкою, дефіс-мінус, крапку (період), LOW LINE (підкреслення) та Близький DOT допускаються.

У ASCII символів і знаків пунктуації, також досить велика група Unicode символів, виключених з назв, оскільки вони є більш корисними як розділювачі в контекстах, де імена XML використовуються поза XML документами; работа ціеї групи дає умови жорстких гарантій про те, що не може бути елементом XML ім'я. Символ #x037E, грецький знак питання, не є сумісним, тому що коли воно стає нормалізованою комою, яка може змінити зміст об'єкта літери.

Names and Tokens/Імена та лексеми

Літеральні дані це будь-який рядок, укладений в лапки і не містить знаків лапок, які використовуються в якості обмежувачів цього рядка. Літери використовуються для спеціфікації вмісту внутрішніх примірників/internal entities (EntityValue), значень атрибутів (AttValue) і зовнішніх ідентифікаторів (SystemLiteral). Зверніть увагу, що SystemLiteral може бути розібраний без сканування розмітки.

Literals/Літери

2.4 Символьні дані та розмітки

Текст складається з суміші символьних даних та розмітки. [Визначення: Розмітка вводиться у вигляді стартових міток (тегів), кінцевих міток (тегів), міток (тегів) порожніх елементів, посилань на екземпляри, символьних мнемонік, коментарів, обмежувачів розділів CDATA, оголошень типу документа, інструкцій процесу, оголошень XML, текстових об'яв та будь-яких прогалин у верхньому рівні примірника документа (тобто поза елементом документа і не усередині іншої розмітки).]

[Визначення: Весь текст, який не є розміткою, утворює символьні дані документа.]

Символ амперсанда (&) і ліва кутова дужка (<) можуть з'являтися у своїй літеральній формі тільки при використанні в якості обмежувачів розмітки або в коментарях, інструкціях процесу або розділах CDATA. Якщо їх необхідно використати ще де-небудь, вони зобов'язані вводитись у вигляді послідовності, з використанням цифрової мнемонікі або рядка "&" і "<" відповідно. Права кутова дужка (>) може бути представлена рядком ">" і зобов'язана, для забезпечення сумісності, вводитись за допомогою бігучої-послідовності ">" або символьної мнемонікі, якщо з'являється в рядку "]]>" всередині вмісту, і якщо цей рядок не означає кінець розділу CDATA.

Символьні дані у вмісті елементів - це будь-який рядок символів, що не містить початкових обмежувачів або іншої розмітки. У розділі CDATA символьних дані - це будь-який рядок символів, не включи закриваючий ограничуючий розділ CDATA - """.

Для того, щоб значення атрибутів могли містити одинарні та подвійні лапки, апостроф, або символ одинарної лапки(') може бути представлений у вигляді "'", а символ подвійної лапки (") - як """.

Character Data/Символьні Дані

2.5 Коментарі

[Визначення: Коментарі можуть з'являтися в будь-якому місці документа поза розміткою; крім того, вони можуть з'являтися всередині оголошення типу документа в тих місцях, які допускаються граматикою. Вони не є частиною символьних даних документа: процесор XML може, але не повинен давати програмі можливість запитувати текст коментарів. Для забезпечення сумісності рядок "--" (double-hyphen/подвійний дефіс) зобов'язаний не з'являтися всередині коментарів.] Посилання на примірники параметрів не розпізнається всередині коментарів.

Коментарі

<!-- оголошення <head> & <body> -->

<!-- B+, B, or B--->

2.6 Інструкції по обробці

[Визначення: Інструкції по обробці (PIs) allow documents to contain instructions for applications.]

Processing Instructions/Інструкції по обробці

Інструкції по обробці не є частиною символьних даних документа і передаються безпосередньо програмі. Інструкції по обробці починаються вказівкою на "мету" (PITarget) для ідентифікації програми, якій надсилається інструкція. Імена цілей, такі як "XML", "xml" і т.д., зарезервовані для можливості стандартизації в цій та майбутніх версіях даної специфікації. Механізм XML "нотацій" може використовуватися для формального оголошення цілей Інструкції по обробці. Посилання на екземпляр параметра не розпізнає всередині Інструкції по обробці.

2.7 Розділи CDATA

[Визначення: Розділи CDATA можуть з'являтися там же, де і символьних дані; вони використовуються для втечі-блоків тексту, що містить символи, які інакше будуть розпізнаватися як розмітка. Розділи CDATA починаються рядком "<![CDATA[" і закінчуються рядком "]]>":]

Розділи CDATA

Внутри раздела CDATA только строка CDEnd распознаётся как разметка, так что амперсанд и левая угловая скобка могут появляться в своей литеральной форме: они не должны (и не могут) быть указаны в escape-последовательности с использованием "<" и "&". Раздел CDATA не может вкладываться.

В якості прикладу в розділі CDATA, де "<greeting>" і "</greeting>" розпізнаються як символьних дані, а не розмітка:

<![CDATA[<greeting>Hello, world!</greeting>]]> 

2.8 Пролог і декларація типу документа

[Визначення: документи XML 1.1 повинні починатися з декларації XML, що визначає версію XML що використовується.] Наприклад, нижче наводиться повний документ XML 1.1, добре сформований, але не дійсний:

<?xml version="1.1"?>
<greeting>Hello, world!</greeting>

Але нижче поданий документ XML 1.0, оскільки він не має XML формування:

<greeting>Hello, world!</greeting>

Функція розбівки в XML документі полягає в тому, щоб описати його структуру зберігання і логічну структуру і об'єднати парні атрибути "ім'я-значення" з його логічною структурою. XML надає механізм (декларація типу документа) для визначення перешкоди на логічну структуру і підтримання використання заздалегідь визначених одиниць зберігання. [Визначення: XML документ є дійсним, якщо він пов'язаний декларацією типу документа і якщо цей документ у відповідності з обмеженнями, виражений в ній.]

The document type declaration MUST appear before the first element in the document.

Пролог

[Визначення: оголошення типу документа XML містить або вказує на оголошення розмітки, що надає грамматику для класу документів. Ця граматика відома як визначення типу документа або DTD. Оголошення типу документа може вказувати на зовнішній піднабір (особливий вид зовнішнього примірника), що містить оголошення розмітки, чи може безпосередньо містити об'яви розмітки у внутрішньому піднаборі, або може мати і те, і інше. DTD документа складається із двох з'єднаних піднаборів.]

[Визначення: оголошення розмітки це оголошення типу елемента, оголошення списку атрибутів та оголошення примірника, або оголошення нотації.] Ці оголошення можуть повністю або частково міститись всередині примірників параметрів, як описано нижче в розділах про правильне формування та обмеження правильності. Додаткову інформацію див. в 4 Фізичні структури.

Document Type Definition/Визначення типу документа

Майте на увазі, що можна побудувати добре сформований документ, що містить doctypedecl що ні містить точок на зовнішній підмножині ні містить внутрішньої підмножини.

Оголошення розмітки можуть бути виконані повністю або частково шляхом заміщення тексту примірників параметрів. Далі в цій специфікації продукти окремих терміналів (elementdecl, AttlistDecl і т.д.) описують оголошення після всіх примірників параметрів, які були включені.

Посилання на примірники параметрів розпізнаються в будь-якому місці DTD (зовнішніх або внутрішніх поднаборах і зовнішніх примірниках параметрів), крім літералів, інструкції процесів, коментарів та вмістів ігнорування умовних секцій (див. 3.4 Розділи умов). Вони розпізнаються також у літералах значення екземпляра. Використання примірників параметрів у внутрішньому поднаборі обмежено так, як описано нижче.

Подібно до внутрішнього піднабору, зовнішній поднабор і будь-який зовнішній PE, на який є посилання в DeclSep, повинен складатися з серії повних оголошень розмітки типів, допустимих нетермінальной символьне markupdecl, перемежаемих пробілами або посиланнями на PE. Однак частини вмісту зовнішнього поднабора чи цих зовнішніх PE можуть умовно ігноруватися шляхом використання конструкцій розділів умов; це не допускається у внутрішньому піднаборі.

External Subset/Зовнішній Піднабір

Зовнішній піднабір і зовнішній PE відрізняються також від внутрішнього піднабора тим, що посилання на дозволені PE всередині оголошень розмітки, а не тільки між оголошеннями розмітки.

Приклад документа XML з оголошенням типу документа:

<?xml version="1.1"?>
<!DOCTYPE greeting SYSTEM "hello.dtd">
<greeting>Hello, world!</greeting> 

Системний ідентифікатор "hello.dtd" задає адреса (посилання URI) на DTD для даного документа.

Оголошення може бути також дано місцево, як у наступному прикладі:

<?xml version="1.1" encoding="UTF-8" ?>
<!DOCTYPE greeting [
<!ELEMENT greeting (#PCDATA)>
]>
<greeting>Hello, world!</greeting>

Якщо обидві зовнішні і внутрішні підмножини використовуються як внутрішні підмножини повинні розглядатися перед виникненням зовнішньої підмножини. Це те, що організація і атрибут список декларацій у внутрішньому підмножини над цим у зовнішньому підмножини.

Якщо документ є добре сформованим або дійсним XML 1.0, і за умови, що вона не містить будь-яких символів в діапазоні [#x7F-#x9F], окрім як символ втечі, він може бути добре сформованим або дійсним XML 1.1, відповідно, просто шляхом зміни номера версії.

2.9 Відокремлена декларація Документу

Оголошення розмітки можуть впливати на зміст документа при передачі його від процесора XML програмі; прикладами можуть служити значення атрибутів за замовчуванням і оголошення примірників. Окреме оголошення документа, який може з'являтися як компонент оголошення XML, сигналізує про те, є чи ні такі оголошення, які є зовнішніми по відношенню до примірнику документа або примірника параметрів. [Визначення: зовнішнє оголошення розмітки визначено як оголошення розмітки, що з'являється у зовнішньому піднаборі або в EP (зовнішньому або внутрішньому, останній включається, оскільки від неревіряючих процесорів не потрібно їх читати).]

Standalone Document Declaration/Окреме Оголошення Документа

В окремому оголошенні документа, значення "yes" означає відсутність зовнішніх оголошень розмітки, що впливають на інформацію, віддану від процесора XML програмі. Значення "no" означає, що є або можуть бути такі зовнішні оголошення розмітки. Зауважте, що окреме оголошення документа означає лише існування зовнішніх оголошень. Існування в документі посилань на зовнішні примірники, якщо ці примірники оголошені всередині, не змінює їх окремий статус.

Якщо зовнішні оголошення розмітки відсутні, окреме оголошення документа не має сенсу. Якщо є зовнішні оголошення розмітки, але відсутні окремі оголошення документа, приймається значення "no".

Будь-який документ XML, в якому standalone="no", може бути конвертований за алгоритмом в окремий документ, що може бути необхідно для деяких мережевих програм.

Приклад оголошення XML з оголошенням окремого документа:

<?xml version="1.1" standalone='yes'?>

2.10 Обробка пробілів

Процесор XML зобов'язаний завжди передавати програмі всі символи в документі, що не є розміткою. Перевіряючий XML процесор зобов'язаний також інформувати програму про те, які з цих символів утворюють прогалини, що з'являються у вмісті елементу.

Спеціальний атрибут, званий xml:space, може бути приєднаний до елементу для того, щоб сигналізувати про намір зберегти пробіл в даному елементі для використання додатком. У valid/правильних документах цей атрибут, як і деякі інші, зобов'язаний бути оголошений, якщо він використовується. Якщо оголошений, він зобов'язаний бути даним як тип перераховування, значення якого - одне або обидва - "default" і "preserve". Наприклад:

<!ATTLIST poem  xml:space (default|preserve) 'preserve'>
<!ATTLIST pre xml:space (preserve) #FIXED 'preserve'>

Значення "за замовчуванням" ("default") означає, що додаток за замовчуванням в режимі обробки білого простору є прийнятним для даного елемента, а значення "зберегти" ("preserve"), вказує на намір про те, що программи повинні зберегти весь білий простір. Це оголошуе намір поширюватися на всі елементи змісту цього елемента в якому він визначений, якщо не переписане іншим, наприклад, у xml:space атрибуті. Ця специфікація не надає сенсу будь-якому значенню xml:space не "за замовчуванням" ("default") і "зберегти" ("preserve"). Подібна ситуація є помилкою, що буде вказано для інших значень, також XML процесор може повідомити про помилку, або може стягнути ігноруючий атрибут специфікації, або подання (помилкової) вартості заявки. Заявки можуть ігнорувати або відкидати помилкові значення.

Кореневий елемент будь-якого документа вважається що не має жодних намірів щодо обробки прогалин додатком, якщо тільки він не надає значення для даного атрибуту або якщо атрибут не оголошено всередині значення за замовчуванням.

2.11 Обробка кінця рядка

Звичайно XML структується елементами розподіленими на рядки, за для крашого редагування, та розпоширюються компьютерними програмами. Ці рядки, як правило, розділені деякими комбінаціями символів повернення каретки/CARRIAGE RETURN (#xD) і рядок/LINE FEED (#xA).

За для спрощення завдання програмі, XML процесори повинні діяти так, якби він нормалізовано розбирався зі всіх строк у зовнішніх суб'єктів (у тому числі документ особи) на вході, до розбору, шляхом переведення всіх наступних на один символ #xA:

1. дві послідовності символів #xD #xA

2. дві послідовності символів #xD #x85

3. єдиний символ #x85

4. єдиний символ #x2028

5. будь-які #xD, що йдуть не відразу після #xA або #x85.

Символи #x85 і #x2028 не можуть бути визнані і достовірно переведені до тих пір, поки особа кодування декларації (якщо вона існує) не була прочитана. Таким чином, це є фатальною помилкою, використовувати їх в XML заяві чи тексті декларації.

2.12 Визначення мови

При обробці документа часто використовується ідентифікація природної або формальної мови, на якій написано вміст. Спеціальний атрибут, званий xml:lang, може бути вставлений до документа, щоб визначити мову, що використовується у вмісті і значеннях атрибутів будь-якого елемента в XML документі. У правильних документах цей атрибут, як і деякі інші, зобов'язаний бути оголошений, якщо використовується. Значеннями атрибута є ідентифікацією мови, як це визначено в [IETF RFC 3066], Tags for the Identification of Languages, або його наступника, крім того, порожний рядок може бути вказаний.

(Випуски з 33 по 38 вилучені.)

Наприклад:

<p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>
<p xml:lang="en-GB">What colour is it?</p>
<p xml:lang="en-US">What color is it?</p>
<sp who="Faust" desc='leise' xml:lang="de">
<l>Habe nun, ach! Philosophie,</l>
<l>Juristerei, und Medizin</l>
<l>und leider auch Theologie</l>
<l>durchaus studiert mit hei&#xDF;em Bem&#xFC;h'n.</l>
</sp>

Формулювання зазначеного xml:lang відноситься до елементу, коли він визначається (у тому числі значення його атрибутів), і всі елементи його змісту, якщо перевизначено з іншого екземпляру xml:lang. Зокрема, порожні значення xml:lang використовуються елементи B для перевизначення специфікації xml:lang за яким додається елемент, без вказівки на іншу мову. У B, то вважається, що немає мови наявної інформації, так само, як якщо xml:lang не був зазначений в B або будь-якому з його предків. Застосування визначає, які елементи в атрибуті є значенням і які його частини є характером вмісту, якщо це розглядається в якості значення залежної мови та описується xml:lang.

Проста декларація з xml:lang може приймати форму

xml:lang CDATA #IMPLIED

однак конкретні значення за замовчуванням також можуть бути надані, якщо це доречні. У колекції французьких віршів Англійська для студентів, зазначає на Англійській, з xml:lang атрибут може бути оголошений таким чином:

<!ATTLIST poem   xml:lang CDATA 'fr'>
<!ATTLIST gloss  xml:lang CDATA 'en'>
<!ATTLIST note   xml:lang CDATA 'en'>

2.13 Перевірка цілосності

Всі XML структури розбираються (у тому числі документ особи) повинні бути повністю нормалізовані у відповідності з визначенням B Визначення характеру нормалізації, що доповнена наступними визначеннями відповідних конструкцій для XML:

1. На заміну тексту всіх структур обробки

2. Всі тексти, що відповідають, у зв'язку з одним з таких виробництв:

   1. CData

   2. CharData

   3. content

   4. Name

   5. Nmtoken

Однак документ до сих пір добре сформований, навіть якщо він не є повністю нормалізаним. XML процесор повинен забезпечувати користувачеві можливість переконатися в тому, що цей документ обробляється в повному нормалізованому вигляді, і представити доповідь про застосування чи то є вона чи ні. Можливість перевірити, чи не слід вибирати тільки у випадку введення тексту сертифікована, як це визначено B Визначення характеру нормалізації.

Перевірка повної нормалізації повинна вестись таким чином, щоб спочатку упевнитися в тому, що юридична особа включає-нормалізовану форму, як це визначено B Визначення характеру нормалізації і потім перевірити, що жоден з відповідних конструкцій, перерахованих вище, починає (після символу посилання будуть розширені) з складанням характеру, як це визначено B Визначення характеру нормалізації. Неприєднання перевірки процесори повинні ігнорувати можливі ненормалізовані сутності, які будуть викликані включенням зовнішніх організацій, що вони не читають.

Якщо при перевірці повної нормалізації, процесор стикається з персонажами, для яких перша не може бути визначена, нормалізації властивостей (наприклад, символи введені у версії Unicode [Unicode] пізніше, ніж той, що використовується у вживаному процесорі), то процесор може, на користувачів опції, ігнорувати будь-які можливі ненормалізованого виду викликані цими символами. Можливість ігнорувати ці ненормалізовані види НЕ ПОВИННА бути обрана шляхом застосування, коли надійність і безпека є найважливішими.

XML процесори НЕ повинні перетворювати вхідні дані щоб бути в повній мірі нормалізованими. XML програми, які створюють на виході XML 1.1 з будь-якої XML 1.1 і XML 1.0 внутрішньої побудови, повинен забезпечити повну нормалізацію на виході, але не є необхідною для внутрішньої обробки бланків щоб бути повністю нормалізованими.

Мета цього розділу полягає в тому, щоб закликати до рішучіх процесорів XML для забезпечення того, щоб розробники XML документів належним чином їх унормалізовували, так що XML програми можуть зробити тести, такі, як особистість порівняння рядків, не турбуючись про різні можливі "написання" поєднань Unicode, що дозволяється.

Коли суб'єкти передині не в Unicode кодуванні, якщо процесор перекодовує їх в Unicode, то слід використовувати нормалізації Транскодер.

3.1 Початкові і кінцеві теги, теги порожніх елементів

[Визначення: На початку кожного непорожній XML елемент характеризується початковий тег.]

Тег початку

Name у початковому і кінцевому тегах задає тип елементу. [Визначення: Пари Name-AttValue (Ім'я-Значення атрибута) називаються специфікаціями атрибутів елемента], [Визначення: з Name в кожній парі, званим ім'ям атрибута] і [Визначення: вмістом AttValue (текстом між обмежники ' або ") в якості значення атрибуту.] Зверніть увагу, що порядок специфікації атрибутів у початковому теге або в теге порожнього елемента не має значення.

Приклад початкового тега:

<termdef id="dt-dog" term="dog">

[Визначення: закінчення кожного елемента, започаткованого початковим тегом, зобов'язана бути зазначено кінцевим тегом, що містить ім'я, що відображає тип елемента, як це було дано в початковому тегу:]

End-tag/Кінцевий Тег

</termdef>

[Визначення: : Текст між початковим і кінцевим тегамі називається вмістом елемента:]

Content of Elements/Вміст елементу

[Визначення: Елемент без вмісту називається порожнім.] Пустой елемент представлений або початковим тегом, після якого безпосередньо слід кінцевий тег, або тегом порожнього елементу. [Визначення: Тег порожнього елемента має особливу форму:]

Tags for Empty Elements/Теги порожніх Елементів

Теги порожнього елемента ожуть використовуватися для будь-якого елемента, що не має вмісту, незалежно від того, оголошений він ключовим словом EMPTY чи ні. Для цілей взаємодії тег порожнього елемента повинен використовуватися (і тільки він повинен використовуватися) для тих елементів, які оголошені як EMPTY.

Examples of empty elements/Приклади порожніх елементів:

<IMG align="left"
src="http://www.w3.org/Icons/WWW/w3c_home" />
<br></br>
<br/>

3.2 Визначення типу елемента

Структура елемента XML документа може, для цілей перевірки, бути обмежена шляхом використання оголошень типу елемента і списку атрибутів. Оголошення типу елемента обмежує вміст елемента.

Оголошення типу елемента часто обмежують типи елементів, які можуть з'являтися як нащадків елемента. Процесор XML, за вибором користувача, може видавати попередження, якщо в рекламі згадується тип елемента, для якого відсутня реклама, але це не є помилкою.

[Визначення: Оголошення Типа елемента має форму:]

Element Type Declaration/Оголошення Типу елементу

де Name задає тип оголошуємо елементу.

<!ELEMENT br EMPTY>
<!ELEMENT p (#PCDATA|emph)* >
<!ELEMENT %name.para; %content.para; >
<!ELEMENT container ANY>

<!ELEMENT spec (front, body, back?)>
<!ELEMENT div1 (head, (p | list | note)*, div2*)>
<!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*>

<!ELEMENT p (#PCDATA|a|ul|b|i|em)*>
<!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* >
<!ELEMENT b (#PCDATA)>

3.3 Визначення списку атрибутів

Атрибути використовуються для ассоціірованія пар ім'я-значення з елементами. Специфікації атрибутів можуть з'являтися тільки в початкових тегах і тегах порожніх елементів, тому продукції / productions, що використовуються для їх розпізнавання, з'являються в розділі 3.1 Початкові і кінцеві теги, теги порожніх елементів. Оголошення списків атрибутів можуть використовуватися:

• Щоб визначити набір атрибутів, що відносяться до даного типу елемента.

• Щоб встановити тип обмежень для цих атрибутів.

• Щоб забезпечити значення за замовчуванням для атрибутів

[Визначення: Оголошення списку атрибутів визначають ім'я, тип даних і значення за замовчуванням (якщо є) кожного атрибуту, асоційованого з даним типом елемента:]

Attribute-list Declaration/Оголошення Списку атрибутів

Name в правилі AttlistDecl - це тип елемента. За вибором користувача, процесор XML може видавати попередження, якщо атрибути оголошуються для типу елемента, який сам не визначений, але це не є помилкою. Name в правилі AttDef - це ім'я атрибута.

Якщо для даного типу елемента надано більше одного AttlistDecl, то їх вміст об'єднується. Якщо для одного атрибута даного типу елемента надано більше одного визначення, то перше оголошення підключається, а інші ігноруються. Для цілей взаємодії, творці DTD можуть обрати надання максимум одного оголошення списку атрибутів для даного типу елемента, максимум одного визначення атрибута для даного імені атрибута в оголошенні списку атрибутів та мінімум одного визначення атрибута в кожному оголошенні списку атрибутів. Для цілей взаємодії, процесор XML може, за вибором користувача, видавати попередження, якщо дається більш одного оголошення списку атрибутів для даного типу елемента або дано більше одного визначення атрибута для даного атрибуту, але це не є помилкою.

<!ATTLIST termdef
id      ID      #REQUIRED
name    CDATA   #IMPLIED>
<!ATTLIST list
type    (bullets|ordered|glossary)  "ordered">
<!ATTLIST form
method  CDATA   #FIXED "POST">

<!ENTITY d "&#xD;">
<!ENTITY a "&#xA;">
<!ENTITY da "&#xD;&#xA;">

a="
xyz"

x y z

#x20 #x20 x y z

a="&d;&d;A&a; &a;B&da;"

A #x20 B

#x20 #x20 A #x20 #x20 #x20 B #x20 #x20

a=
"

A

B
"

#xD #xD A #xA #xA B #xD #xA

#xD #xD A #xA #xA B #xD #xA

3.4 Розділи умов

[Визначення: Розділи умов є частиною зовнішнього поднабора оголошення типу документа і включені або виключені з логічної структури DTD, що грунтується на ключовому слові, яке їм управляється.]

Conditional Section/Розділи Умов

<!ENTITY % draft 'INCLUDE' >
<!ENTITY % final 'IGNORE' >
<![%draft;[
<!ELEMENT book (comments*, title, body, supplements?)>
]]>
<![%final;[
<!ELEMENT book (title, body, supplements?)>
]]>

4.1 Посилання символів і екземплярів

[Визначення: Посилання символу посилається на специфічний символ в наборі символів ISO/IEC 10646, наприклад, посилання на символ, не доступний прямо з пристрою вводу.]

Character Reference/Символьні посилання

Якщо посилання символу починається з "&#x", цифри і букви аж до кінцевого; дають 16-річне уявлення кодової точки входу символу ISO/IEC 10646. Якщо вона починається просто з "&#", то цифри аж до кінцевого; дають 10-річне уявлення кодової точки входу символу.

[Визначення: Посилання примірника посилається на матеріали, іменованих примірника.] [Визначення: Посилання на загальні розбираємі екземпляри використовують амперсанд (&) і крапку з комою (;) як розділювач.] [Визначення: Посилання примірника параметра використовує знак відсотка (%) і крапку з комою (;) як розділювач.]

Entity Reference/Посилання примірника

Приклади посилань на символи і екземпляри:

Type <key>less-than</key> (&#x3C;) to save options.
This document was prepared on &docdate; and
is classified &security-level;.

Приклад посилання на примірник параметру:

<!-- declare the parameter entity "ISOLat2"... -->
<!ENTITY % ISOLat2
SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" >
<!-- ... now reference it. -->
%ISOLat2;

4.2 Визначення примірників

[Визначення: Примірники оголошуються так:]

Entity Declaration/Оголошення примірника

Name ідентифікує екземпляр в посиланням на екземпляр або, у випадку неразбіраемого примірника, у значенні атрибуту ENTITY або ENTITIES. Якщо один і той же екземпляр оголошено більше одного разу, перше виявлене оголошення підключається; за вибором користувача процесор XML може видавати попередження, якщо примірники оголошуються кілька разів.

<!ENTITY Pub-Status "This is a pre-release of the specification.">

<!ENTITY open-hatch
SYSTEM "http://www.textuality.com/boilerplate/OpenHatch.xml">
<!ENTITY open-hatch
PUBLIC "-//Textuality//TEXT Standard open-hatch boilerplate//EN"
"http://www.textuality.com/boilerplate/OpenHatch.xml">
<!ENTITY hatch-pic
SYSTEM "../grafix/OpenHatch.gif"
NDATA gif >

4.3 Аналіз та перегляд примірників

<?xml encoding='UTF-8'?>
<?xml encoding='EUC-JP'?>

4.4 Обробка XML процесором примірників і посилань

У таблиці нижче коротко викладаються умови, в яких характер літератури, особа літератури, а також виклики в нерозбірні суб'єкти можуть з'явитися і необхідного поведінки в XML процесора в кожному конкретному випадку. Етикетки в лівій колонці описуються визнання контексті:

посилання у вмісті

як посилання де-небудь після початкового тега і перед кінцевим тегом елемента; відповідає нетермінальному вмісту.

посилання в значенні атрибуту

як посилання або в значенні атрибуту у початковому тегу, або як значення за замовчуванням в оголошенні атрибута; відповідає нетермінальному AttValue.

з'являється як значення атрибуту

як Name, не посилання, що з'являється або як значення атрибуту, який оголошений як тип ENTITY, або як одна з трьох розділених пробілами лекс - у значенні атрибуту, який оголошений як тип ENTITIES.

посилання в значенні примірника

як посилання в літеральном значенні примірника в оголошенні екземпляр параметра або внутрішнього примірники; відповідає нетермінальному EntityValue.

посилання в DTD

як посилання всередині зовнішнього або внутрішнього поднабора DTD, але поза EntityValue, AttValue, PI, Comment, SystemLiteral, PubidLiteral, або вмісту ігнорування секції умов (див. 3.4 Секції Умов).

.

<!ENTITY % YN '"Yes"' >
<!ENTITY WhatHeSaid "He said %YN;" >

<!ENTITY EndAttr "27'" >
<element attribute='a-&EndAttr;>

4.5 Конструкція виміщаючого тексту для Внутрішнього примірника

При обговоренні питання про лікування осіб, корисно розрізняти дві форми організації вартості. [Визначення: для внутрішньої організації, в літеральній особі значення процитованого рядку насправді присутня в декларації організації, що відповідає тиму, що не є терміналом EntityValue.] [Визначення: Для зовнішніх особою, літеральні значення організації точний текст, що міститься в обличчя.] [Визначення: Для внутрішнього органу, заміна тексту зміст цього органу, після заміни символьних посилань і параметрів освітами посилання.] [Визначення: Для зовнішнього органу, заміна тексту зміст цього органу, після зачистки тексті декларації (залишаючи навколо будь-якої пробіл), якщо такий є, але без будь-якої заміни символьних посилань або параметр освічений літературою.]

Літеральное значення примірника, дане в оголошенні внутрішнього примірника (EntityValue), може містити посилання на символ, примірник параметра і загальний екземпляр. Такі посилання зобов'язані бути повністю всередині літерального значення екземпляра. Реальний заміщуючих текст, який включається (або включені в літеральному значенні) так, як описано вище, повинен містити заміщуючих текст будь-якого примірника параметра, на який є посилання, і повинен містити символ, на який є посилання, замість будь-яких мнемонік символів у літеральном значенні примірники; однак посилання загального примірника зобов'язані бути залишені без змін, неразвернутимі. Наприклад, якщо є таке оголошення:

<!ENTITY % pub    "&#xc9;ditions Gallimard" >
<!ENTITY   rights "All rights reserved" >
<!ENTITY   book   "La Peste: Albert Camus,
&#xA9; 1947 %pub;. &rights;" >

то заміщуючих текст примірника "book" буде:

La Peste: Albert Camus,
© 1947 Éditions Gallimard. &rights;

Посилання загального примірника "&rights;", який повинен бути розгорнуто, змушує посилання "&book;" з'явитися у вмісті документа або в значенні атрибуту.

Ці прості правила можуть взаємодіяти вельми складно; детальне обговорення складного прикладу наведено в C Розширення особ характеру і літералів.

4.6 Попередньовизначені примірники

[Визначення: Мнемонікі символів можуть використовуватися для виділення лівої кутової дужки, амперсанда та інших обмежувачів. Для цих цілей специфицирован набір загальних мнемонік (amp, lt, gt, apos, quot). Цифрові мнемонікі можуть також використовуватися; вони розгортаються відразу при виявленні і повинні розглядатися як символьних дані, так що цифрові мнемонікі "<" та "&" можуть використовуватися для виділення < і &, якщо вони з'являються в символьних даних.]

Всі XML процесори зобов'язані розпізнавати ці мнемонікі незалежно від того, оголошені вони, чи ні. Для цілей взаємодії, правильні документи XML повинні оголошувати ці екземпляри, як і будь-які інші, до їх використання. Якщо мнемонікі lt або amp оголошуються, то вони зобов'язані бути оголошені як внутрішні екземпляри, чий заміщуючих текст є мнемонікой відповідного символу (знаку "менше-ніж" або амперсанда), який виділяется; для цих примірників необхідно подвійне виділення, щоб посилання на них давали правильно сформований результат. Якщо примірники gt, apos, або quot оголошуються, вони повинні бути оголошені як внутрішні екземпляри, чий заміщуючих текст представляє із себе одиночний escape'іруемий символ (або символьними посиланнями-мнемоніку на цей символ; подвійне escapi'рованіе тут не обов'язково, але й не зашкодить ). Наприклад:

<!ENTITY lt     "&#38;#60;">
<!ENTITY gt     "&#62;">
<!ENTITY amp    "&#38;#38;">
<!ENTITY apos   "&#39;">
<!ENTITY quot   "&#34;">

4.7 Визначення нотації

[Визначення: Нотацію ідентифікують по імені формат неразбіраемих примірників, формат елементів, які породили атрибут нотації, або додаток, якому адресується інструкція процесу.]

[Визначення: Оголошення нотації надають ім'я нотації для використання в оголошеннях примірника і списку атрибутів і в специфікаціях атрибутів, а також зовнішній ідентифікатор для нотації, що може дозволити процесору XML або його клієнтського додатка локалізувати допоміжне додаток, здатне обробити дані в цiй нотації.]

Notation Declarations/Визначення нотації

Процесори XML зобов'язані надавати програмам імена та зовнішній (е) ідентифікатор (и) будь-який нотації, оголошеної і має посилання в значенні атрибуту, визначенні атрибута або в оголошенні примірника. Додатково вони (процесори) можуть розгортати зовнішній ідентифікатор в системний ідентифікатор, ім'я файлу або іншу інформацію, необхідну для того, щоб дати додаткові можливість викликати процесор для даних в описаній нотації. (Не буде помилкою, однак, для документів XML, оголошення і звернення до нотації, для яких специфічне для кожної нотацію додаток недоступний в системі, де процесор XML або додаток запущені.)

4.8 Примірник документу

[Визначення: Екземпляр документа служить кореневим об'єктом дерева примірників і стартовою точкою для XML процесора.] Ця специфікація не визначає, як екземпляр документа розміщується процесором XML; на відміну від інших примірників, примірник документа не має імені і може навіть з'явитися у вхідному потоці процесора взагалі без ідентифікації.

5.1 Перевіряючі і неперевіряючі процесори

Відповідні XML процесори діляться на два класи: перевіряючі і неперевіряючі.

Перевіряючі і неперевіряючі процесори, обидва зобов'язані виводити повідомлення про порушення обмежень правильно сформованості даної специфікації у вмісті примірника документа і будь-яких інших розбираємих примірниках, що вони читають.

[Визначення: Перевіряючі процесори зобов'язані, за вибором користувача, повідомляти про порушення обмежень, виражених оголошеннями в DTD, і неможливості виконання обмежень правильності, даних у цій специфікації.] Щоб виконати це, перевіряльники процесори XML зобов'язані читати і обробляти всі DTD і всі зовнішні розбираємося примірники, на які є посилання в документі.

Від непроверяющіх процесорів потрібно лише перевірити примірник документу, включаючи весь внутрішній піднабір DTD, на правильне формування. [Визначення: Хоча вони і не є обов'язковими для перевірки дійсності документа, вони повинні обробити всі заяви, вони читають у внутрішні DTD підмножини і в який-небудь параметр особи, що вони прочитали, до першого посиланням на параметр особи, що вони не читати, то є, вони повинні використовувати інформацію, що міститься в цих декларацій для нормалізації значень атрибутів, включити заміну тексту внутрішніх органів, і постачання за замовчуванням значень атрибутів.] За винятком випадків, коли standalone="yes" вони не повинні процесу організації заяви або атрибут перелік декларацій, що виникають після передачі в параметр орган, який не читав, оскільки організація може міститися головним декларацій, коли standalone="yes" процесори повинні процесі цих декларацій.

Зауважимо, що при обробці недійсних документів з непостійним перевірки процесора застосування не може бути представлена в послідовної інформації. For example, several requirements for uniqueness within the document may not be met, including more than one element with the same id, duplicate declarations of elements or notations with the same name, etc. In these cases the behavior of the parser with respect to reporting such information to the application is undefined. Наприклад, деякі вимоги до унікальності в рамках цього документа не може бути досягнуто, в тому числі понад одного елемента з однаковим кодом, дублювати заяви елементів нотації або з тією ж назвою, і т.д. У цих випадках поведінка парсера щодо звітності таку інформацію, щоб заявка невизначена.

XML 1.1 процесор повинен бути в змозі обробляти як XML 1.0 і XML 1.1 документів. Програми, які генерувати XML повинне сприяти XML 1.0, якщо одна з особливостей XML 1.1 не потрібно.

5.2 Використання XML процесорів

• Деякі добре formedness помилок, особливо тих, які вимагають читанні зовнішніх суб'єктів, може не бути виявлених, не перевірка процесора. Приклади включають в себе обмеження, має назву Оголошення примірників, Аналіз утворень і відсутність рекурсії, а також деякі випадки, описані в якості заборонених в 4.4 Обробка XML процесором примірників і посилань.

• Ця інформація передається від процесора до заявки, може змінюватися в залежності від того, процесор зчитує параметр і зовнішніми суб'єктами. Наприклад, не перевірка процесора може не нормалізувати значення атрибутів, включити заміну тексту внутрішніх органів, або поставка за замовчуванням значення атрибута, в якому це залежить від наступної заяви на зовнішній структурі або параметру утвореня.

Для забезпечення максимальної надійності в Взаємодія між різними XML процесорів, додатки, які використовують неприєднання перевірки процесорів не слід покладатися на який-небудь поведінку, не вимагає таких процесорів. Програми, які вимагають DTD об'єкти, не пов'язані зі схваленням (таких, як Декларація про невиконанні атрибути та внутрішні, які є або можуть бути вказані в зовнішні суб'єкти) слід використовувати перевірку XML процесорами.