Модуляризация XHTML - Определение конформности

Модуляризация XHTML - Определение конформности
[назад] [далее] [содержание]
3. Определение конформности
Содержание
3.1. Конформность типов документов языку хостов XHTML
3.2. Конформность типов документов набору интеграции XHTML
3.3. Конформность модулей семейства XHTML
3.4. Конформность документов семейства XHTML
3.5. Конформность пользовательских агентов семейства XHTML
3.6. Правила именования
3.7. Эволюция модулей XHTML
Данный раздел является нормативным.
Для гарантии максимальной переносимости документов семейства XHTML между пользовательскими агентами семейства XHTML в настоящей спецификации жестко определяются требования конформности для них обоих и для типов документов семейства XHTML. Хотя в данном разделе и имеются определения конформности, они обязательно ссылаются на нормативный текст в настоящем документе, в базовой спецификации XHTML [XHTML1] и в других связанных с ними спецификациях. Чтобы полностью понять требования конформности XHTML, необходимо полностью прочесть все нормативные ссылки.
В этом документе такие ключевые слова как "ДОЛЖЕН", "НЕ ДОЛЖЕН", "ОБЯЗАТЕЛЬНО", "НУЖНО", "НЕ НУЖНО", "СЛЕДУЕТ", "РЕКОМЕНДУЕТСЯ", "МОЖЕТ БЫТЬ" и "НЕОБЯЗАТЕЛЬНО" интерпретируются аналогично тому, как это делается с английскими эквивалентами в [RFC2119].
3.1. Конформность типов документов языку хостов XHTML
Используя как определенные в настоящей спецификации, так и другие модули, вы можете изменять существующие и определять полностью новые типы документов. Такой тип документов является "конформным языку хостов XHTML", если он удовлетворяет следующим критериям:
Тип документа должен быть определен с использованием одного из методов реализации, определенных W3C. На данный момент единственным методом является XML DTD, но скоро появится схема XML. В данном разделе мы будем говорить "DTD", хотя возможны и другие реализации.
DTD, определяющее тип документа, должно иметь уникальный идентификатор в соответствии с определением, данным в правилах именования, использующий в качестве первой метки открытого текстового описания строку "XHTML".
DTD, определяющее тип документа, должно включать, как минимум, модули Structure, Hypertext, Text и List, определенные в настоящей спецификации.
Для каждого из определенных W3C включаемых модулей все элементы, атрибуты, типы атрибутов (включая все обязательные нумерованные списки значений) и все обязательные минимальные модели содержимого должны включаться (и могут расширяться) в модель содержимого типа документа. При расширении моделей содержимого все элементы и атрибуты (а также их типы или обязательные нумерованные списки значений), обязательные в исходной модели содержимого, должны быть обязательными.
В DTD, определяющем тип документа, могут определяться дополнительные элементы и атрибуты. Однако они должны находиться в собственном пространстве имен XML [XMLNAMES].
3.2. Конформность типов документов набору интеграции XHTML
Вы можете определить типы документов, построенные на основе на XHTML, но не соблюдающие его структуру. Такой тип документов является "конформным набору интеграции XHTML", если он удовлетворяет следующим критериям:
Тип документа должен быть определен с использованием одного из методов реализации, определенных W3C. На данный момент единственным методом является XML DTD, но скоро появится схема XML. В данном разделе мы будем говорить "DTD", хотя возможны и другие реализации.
DTD, определяющее тип документа, должно иметь уникальный идентификатор в соответствии с определением, данным в правилах именования, использующий строку "XHTML" НЕ в первой метке открытого текстового описания.
DTD, определяющее тип документа, должно включать как минимум модули Hypertext, Text и List, определенные в настоящей спецификации.
Для каждого из определенных W3C включаемых модулей все элементы, атрибуты, типы атрибутов (включая все обязательные нумерованные списки значений) и все обязательные минимальные модели содержимого должны включаться (и могут расширяться) в модель содержимого типа документа. При расширении моделей содержимого все элементы и атрибуты (а также их типы или обязательные нумерованные списки значений), обязательные в исходной модели содержимого, должны быть обязательными.
В DTD, определяющем тип документа, могут определяться дополнительные элементы и атрибуты. Однако они должны находиться в собственном пространстве имен XML [XMLNAMES].
3.3. Конформность модулей семейства XHTML
В настоящей спецификации определяется метод определения конформных XHTML модулей. Модуль конформен данной спецификации, если он удовлетворяет следующим условиям:
Тип документа должен быть определен с использованием одного из методов реализации, определенных W3C. На данный момент единственным методом является XML DTD, но скоро появится схема XML. В данном разделе мы будем говорить "DTD", хотя возможны и другие реализации.
Определяющее модуль DTD должно иметь уникальный идентификатор в соответствии с правилами именования.
Если модуль определен с помощью XML DTD, имена параметрических сущностей в нем должны быть отделены за счет использования уникальных префиксов или с использованием других аналогичных методов.
Определение модуля должно иметь определение с описанием синтаксических и семантических требований к элементам, атрибутам и/или моделям содержимого объявляемого модуля.
В определении модуля не должны заново использоваться имена элементов, определенные в других определенных модулях W3C, за исключением случая, когда модель содержимого и семантика этих элементов идентичны оригиналу или расширению оригинала или когда имена заново используемых элементов находятся в собственном пространстве имен (см. ниже).
Элементы и атрибуты в определении модуля должны быть частью пространства имен XML [XMLNAMES]. Если модуль определен не W3C, а другой организацией, это пространство имен НЕ должно совпадать с пространством имен, в котором определены другие модули W3C.
3.4. Конформность документов семейства XHTML
Конформный документ семейства XHTML - это допустимый экземпляр типа документа, конформного языку хостов XHTML.
3.5. Конформность пользовательских агентов семейства XHTML
Конформный пользовательский агент должен соответствовать всем перечисленным ниже условиям (как определено в [XHTML1]):
Для соответствия рекомендации XML 1.0 [XML] пользовательский агент должен проводить синтаксический разбор документа XHTML и оценивать его правильность. Если пользовательский агент считается агентом с проверкой правильности, в соответствии с [XML] он должен также проверять соответствие документов DTD, на которые они ссылаются.
Если пользовательский агент поддерживает возможности, определенные в настоящей спецификации или обязательные согласно нормативной ссылке, он должен это делать в соответствии со способами, описанными в определении этой возможности.
Если пользовательский агент обрабатывает документ XHTML как общий документ [XML], в качестве идентификаторов фрагментов он должен распознавать только атрибуты типа ID (например, атрибут id большинства элементов XHTML).
Если пользовательский агент не распознает встреченный элемент, он должен продолжить обработку дочернего элемента. В случае текстового содержимого текст должен быть представлен пользователю.
Если пользовательский агент не распознает встреченный атрибут, он должен проигнорировать всю спецификацию атрибута (т.е. атрибут и его значение).
Если пользовательский агент не распознает значение встреченного атрибута, он должен использовать значение этого атрибута по умолчанию.
Если пользовательский агент встречает ссылку на сущность (отличную от заранее определенных сущностей), для которой он не обрабатывал объявления (что могло произойти, если объявление расположено во внешнем подмножестве, которое пользовательский агент не прочел), ссылка на сущность должна генерироваться в виде составляющих ее символов (начиная с амперсанда и заканчивая точкой с запятой).
Во время генерации содержимого пользовательские агенты, если они встречают распознаваемые, но негенерируемые символы или ссылки на символьные сущности, должны представлять документ таким образом, чтобы пользователю было понятно, что корректно сгенерировать документ не удалось.
Пробельные символы должны обрабатываться по следующим правилам. Следующие символы определены в [XML] как пробельные:
пробел ( )
табуляция (	)
возврат каретки ()
перевод строки (
)
Процессор XML приводит коды конца строки, различные в различных в системах, к одному символу перевода строки, который передается в приложение.
Пользовательский агент должен обрабатывать пробельные символы в полученных от процессора XML данных следующим образом:
Все пробельные символы, окружающие элементы блока, должны удаляться.
Комментарии удаляются полностью и не влияют на обработку пробелов. Один пробельный символ в начале или в конце комментария обрабатывается как два пробела.
Если для атрибута 'xml:space' установлено значение 'preserve', все пробельные символы должны сохраняться, а символы перевода строки в блоке не должны преобразовываться.
Если для атрибута 'xml:space' не установлено значение 'preserve':
Начальные и конечные пробельные символы внутри элемента блока должны удаляться.
Символы перевода строки должны преобразовываться в один следующих символов: символ пробела, символ пробела нулевой ширины () или ни в один символ (т.е. удаляться). Выбор в этом случае определяется пользовательским агентом и обусловлен системой письма символов, предшествующих символу перевода строки и следующих за ним.
Последовательность пробельных символов, не включающая символы перевода строки, должна сокращаться до одного символа пробела.
Последовательность пробельных символов, включающая один или несколько символов перевода строки, должна сокращаться точно так же, как один символ перевода строки.
Пробелы в значениях атрибутов обрабатываются в соответствии с [XML].
Примечание (информативное): Определяя способ преобразования символа перевода строки, пользовательский агент должен рассмотреть следующие случаи, когда система письма символов, предшествующих символу перевода строки и следующих за ним, определяет выбор замены. Обработка символов общей системы письма (например, пунктуации) определяется системой письма по другую сторону символа перевода строки:
Если символы, предшествующие символу перевода строки или следующие за ним, относятся к системе письма, в которой пробел используется в качестве разделителя слов, символ перевода строки должен преобразовываться в символ пробела. Примерами таких систем являются латинское, греческое и кириллическое письмо.
Если символы, предшествующие символу перевода строки или следующие за ним, относятся к идеографической системе письма или к системе письма без разделения слов, символ перевода строки должен просто удаляться. Примерами таких систем являются китайское и японское письмо.
Если символы, предшествующие символу перевода строки или следующие за ним, относятся к неидеографической системе письма без разделителя слов, символ перевода строки должен преобразовываться в пробел нулевой ширины () или удаляться. Примерами таких систем являются тайское и кхмерское письмо.
Если не соблюдается ни одно из условий 1 -- 3, символ перевода строки должен преобразовываться в пробел.
Названия систем письма всем символам назначены в техническом отчете TR#24 (Script Names [Названия систем письма]) Юникода [UNICODE].
3.6. Правила именования
Чтобы программы и пользователи могли легко определить отношение типов документов к XHTML, в типах документов языка хостов XHTML должны соблюдаться строгим правилам именования. Имена типов документов, реализованные как определения типов документов XML, определяются с использованием формальных общих идентификаторов (Formal Public Identifiers, FPI). В FPI поля разделяются двумя косыми чертами (//). Разные поля должны составляться следующим образом:
Первое поле должно содержать только символ "-" для обозначения частным образом определенного ресурса.
Второе поле должно содержать название организации, ответственной за поддержку этого элемента. Формальная регистрация названий таких организаций не применяется. Каждая организация должна задавать уникальное имя. W3C, например, использует имя W3C.
Третье поле содержит две конструкции: общий класс текста, за которым следует открытое описание текста. Первый символ в третьем поле - открытый класс текста, он должен соответствовать ISO 8879 Clause 10.2.2.1 Public Text Class (ISO 8879, пункт 10.2.2.1 Открытый класс текста). Только у конформных языку хостов XHTML документов открытое описание текста должно начинаться с метки XHTML. Если тип документа конформен набору интеграции, открытое описание текста должно содержать строку XHTML. Кроме того, это поле должно содержать определенный организацией уникальный идентификатор (например, MyML 1.0). Он должен состоять из уникального имени и идентификатора версии, который может обновляться по мере развития типа документа.
Четвертое поле определяет язык элемента (например, EN).
С использованием этих правил именем конформного языку хостов XHTML документа может быть -//MyCompany//DTD XHTML MyML 1.0//EN. Именем конформного семейству XHTML модуля может быть -//MyCompany//ELEMENTS XHTML MyElements 1.0//EN. Именем конформного набору интеграции XHTML типа документа может быть -//MyCompany//DTD Special Markup with XHTML//EN.
3.7. Эволюция модулей XHTML
Каждому модулю, определенному в настоящей спецификации по правилам именования, перечисленным в предыдущем разделе, дается уникальный идентификатор. Со временем модуль может развиваться. Логическим следствием такой эволюции может быть то, что некоторые аспекты модуля перестанут быть совместимыми с предыдущим определением. Чтобы гарантировать дальнейшую работу типов документов, определенных в соответствии с модулями настоящей спецификации, связанные с изменяемым модулем идентификаторы должны обновляться. В частности, формальный открытый идентификатор и системный идентификатор модуля изменяются за счет изменения идентификатора версии, включаемого в каждый из них. Типы документов, в которых будет использоваться новая функциональность, нужно будет так же обновить.
Кроме того, более ранние версии модуля будут по-прежнему доступны благодаря более старым уникальным идентификаторам. Таким образом, типы документов, разработанные с использованием модулей XHTML, будут работать с использованием своих оригинальных определений даже при развитии и расширении набора. Аналогично, экземпляры документов, написанные по таким типам, будут соответствовать более ранним определениям модуля.
Другим авторам типов документов и модулей семейства XHTML настоятельно рекомендуется использовать эту же стратегию, чтобы обеспечить постоянную работу типов документов, построенных на базе этих модулей, и экземпляров документов на базе этих типов.
[назад] [далее] [содержание]
содержание | 2 | Фотографии

Используются технологии uCoz