Модуляризация XHTML - Построение модулей DTD

Модуляризация XHTML - Построение модулей DTD
[назад] [далее] [содержание]
Г. Построение модулей DTD
Содержание
Г.1. Именование параметрических сущностей
Г.2. Определение пространства имен модуля
Г.2.1. Подмодуль квалифицированных имен
Г.2.2. Подмодули объявлений
Г.2.3. Использование модуля как автономного DTD
Г.2.4. Отличительные особенности пространств имен
Данный раздел является нормативным.
Модули XHTML реализуются как фрагменты DTD. Когда эти фрагменты собираются в определенном порядке (описанном в разделе "Разработка DTD с определенными и дополнительными модулями"), результирующее DTD представляет собой полный тип документа. Затем это представление может использоваться для проверки корректности экземпляров этого типа документов.
Ключом к объединению фрагментов в имеющее смысл DTD являются правила, используемые для определения фрагментов. Они определяются в данном разделе. Следуя этим правилам, авторы DTD могут быть уверены в том, что их модули будут корректно взаимодействовать с другими XHTML-совместимыми модулями.
Модули, соответствующие этим правилам, должны также удовлетворять требованиям конформности, определенным в разделе "Конформность модулей семейства XHTML", только тогда они смогут называться модулями семейства XHTML.
Г.1. Именование параметрических сущностей
В настоящей спецификации сущности параметров подразделяются на семь категорий и именуются соответствующим образом с использованием следующих суффиксов:
.mod
суффикс .mod используется, если сущности параметров используются для представления модуля DTD (набора элементов, атрибутов, параметрических сущностей и т.д.). В настоящей спецификации каждый модуль является атомарной единицей и может представляться как отдельная сущность файла.
.module
суффикс .module используется, если сущности параметров используются для управления включением модуля DTD путем использования любого из условных ключевых слов - INCLUDE или IGNORE.
.qname
суффикс .qname используется, если сущности параметров используются для представления квалифицированного имени элемента. Подробнее о квалифицированных именах см. в разделе "Определение пространства имен модуля".
.content
суффикс .content используется, если сущности параметров используются для представления модели содержимого типа элемента.
.class
суффикс .class используется, если сущности параметров используются для представления элементов одного и того же класса.
.mix
суффикс .mix используется, если сущности параметров используются для представления набора типов элементов различных классов.
.attrib
суффикс .attrib используется, если сущности параметров используются для представления группы символов, представляющих одну или несколько полных спецификаций атрибутов в объявлении ATTLIST.
Например, в HTML 4 сущность параметра %block; определена для представления разнотипного набора типов элементов, относящихся к уровню блока. В настоящей спецификации такой сущностью будет %Block.mix;.
При определении сущностей параметров в определенных здесь классах модули должны включать имена сущностей путем использования уникальных префиксов. Например, модель содержимого элемента myelement в модуле mymodule может называться MYMODULE.myelement.content. Возможны и другие схемы. Независимо от используемой схемы, авторы модулей должны прилагать все усилия к обеспечению уникальности имен определяемых ими сущностей параметров, чтобы они не конфликтовали с другими сущностями параметров и чтобы интерфейсные методы модуля были очевидны его пользователям.
Г.2. Определение пространства имен модуля
В XHTML объявленные в модуле элементы и атрибуты должны находиться в определенном пространстве имен XML [XMLNAMES]. Пространство имен определяется произвольным URI. В XHTML в случае реализации модуля с помощью XML DTD пространство имен в модуле должно объявляться специальным образом. Это делается для обеспечения на стадии разбора/проверки корректности документа выбора использования префиксов пространства имен и префикса, используемого для идентификации элементов и атрибутов модуля.
Разработчики контента, которые хотят создавать документы на базе гибридных типов документов, могут использовать префиксы пространства имен XML в элементах из пространства имен XHTML, в элементах из других пространств имен или и в тех, и в других. Для гарантии конформности таких документов языку XHTML и обратной совместимости со средствами, не работающими с пространствами имен, W3C рекомендует разработчикам контента не использовать префиксы пространства имен XML в элементах из пространства имен XHTML. Если разработчики контента заинтересованы в том, чтобы их контент обрабатывался процессорами, поддерживающими пространства имен, W3C также рекомендует определять элементы, не относящиеся к пространствам имен XHTML, с использованием префикса пространства имен XML, а не полагаться на механизмы умолчаний пространства имен XML.
Каждый конформный XHTML модуль, реализованный как XML DTD, должен определять префикс пространства имен XML, используемый по умолчанию, метод изменения этого префикса в экземпляре документа и размеченный раздел для включения обработки этого префикса.
Обратите внимание, что несколько связанных модулей могут и должны быть частью одного пространства имен. Все модули XHTML, например, являются частями одного пространства имен.
Г.2.1. Подмодуль квалифицированных имен
Прежде всего следует определить подмодуль квалифицированных имен (подмодуль представляет собой просто файловую сущность, выделенную так, чтобы она могла встраиваться в нужное место DTD). Подмодуль квалифицированных имен строится с помощью последовательности действий (строка MODULE заменяется соответствующей строкой для нового модуля):
Определите сущность параметра MODULE.prefixed, которая объявляет, используются элементы модуля с префиксными именами пространства имен XML или нет. По умолчанию будет использоваться значение "%NS.prefixed;". Сущность параметра NS.prefixed определяется в модели XHTML по умолчанию как IGNORE и может использоваться в экземплярах документов для переключения префиксов всех включенных пространств имен (включая пространство имен модулей XHTML).
Определите сущность параметра MODULE.xmlns, содержащую идентификатор пространства имен для модуля.
Определите сущность параметра MODULE.prefix, содержащую префикс, который будет использоваться по умолчанию, когда префиксы включены.
Определите сущность параметра MODULE.pfx - "%MODULE.prefix;:" если используется префиксация, и "" в противном случае.
Определите сущность параметра MODULE.xmlns.extra.attrib, содержащую объявление всех атрибутов пространства имен XML, упоминаемых в данном модуле (например, xmlns:xlink). Если для сущности %MODULE.prefixed установлено значение INCLUDE, этот атрибут должен включать, помимо прочего, опредление xmlns:%MODULE.prefix;.
Определите сущность параметра XHTML.xmlns.extra.attrib как MODULE.xmlns.extra.attrib. Обычно эта сущность потом заменяется файлом драйвера типа документа, но если замена не произойдет, это объявление будет использоваться по умолчанию.
Для каждого из определяемых модулем элементов создайте параметрическую сущность вида "MODULE.NAME.qname" для хранения квалифицированного имени. Эта сущность должна иметь значение "%MODULE.pfx;NAME". Таким образом, если используются префиксы, после анализа значением будет "PREFIX:NAME", а если они не используются - "NAME".
Если модуль добавляет атрибуты в элементы, определенные в модулях, не имеющих с данным модулем общих пространств имен, объявите эти атрибуты так, чтобы они использовали префикс %MODULE.pfx. Например:
<ENTITY % MODULE.img.myattr.qname "%MODULE.pfx;myattr" >
Пример подмодуля qname для гипотетического модуля Inventory:





<!ENTITY % NS.prefixed "IGNORE" >
<!ENTITY % Inventory.prefixed "%NS.prefixed;" >

<!ENTITY % Inventory.xmlns "http://www.example.com/xmlns/inventory" >

<!ENTITY % Inventory.prefix "inventory" >

<![%Inventory.prefixed;[
<!ENTITY % Inventory.pfx "%Inventory.prefix;:" >
]]>
<!ENTITY % Inventory.pfx "" >

<![%Inventory.prefixed;[
<!ENTITY % Inventory.xmlns.extra.attrib
"xmlns:%Inventory.prefix; %URI.datatype; #FIXED '%Inventory.xmlns;'" >
]]>
<!ENTITY % Inventory.xmlns.extra.attrib "" >

<!ENTITY % XHTML.xmlns.extra.attrib
%Inventory.xmlns.extra.attrib; >

<!ENTITY % Inventory.shelf.qname "%Inventory.pfx;shelf" >
<!ENTITY % Inventory.item.qname "%Inventory.pfx;item" >
<!ENTITY % Inventory.desc.qname "%Inventory.pfx;desc" >
<!ENTITY % Inventory.sku.qname "%Inventory.pfx;sku" >
<!ENTITY % Inventory.price.qname "%Inventory.pfx;price" >
Г.2.2. Подмодули объявлений
Затем нужно определить один или несколько "подмодулей объявлений". Назначением этих файловых сущностей является объявление списков элементов и атрибутов XML DTD. Модуль объявлений XHTML должен строиться следующим образом:
Определите параметрическую сущность для использования в ATTLIST каждого объявленного элемента. Эта параметрическая сущность должна содержать %NS.decl.attrib; если для %MODULE.prefixed; установлено значение INCLUDE, и %NS.decl.attrib; и "xmlns %URI.datatype; #FIXED '%MODULE.xmlns;'" если для %MODULE.prefixed; установлено значение IGNORE.
Объявите для модуля все элементы и атрибуты. В каждом ATTLIST для элемента включите определенную выше параметрическую сущность таким образом, чтобы все обязательные атрибуты xmlns были доступны каждому элементу в модуле.
Если модуль добавляет атрибуты в элементы, определенные в модулях, не имеющих с данным модулем общих пространств имен, объявите эти атрибуты так, чтобы они использовали префикс %MODULE.pfx. Например:
<ENTITY % MODULE.img.myattr.qname "%MODULE.pfx;myattr" >
<!ATTLIST %img.qname;
%MODULE.img.myattr.qname; CDATA #IMPLIED
>
Это приведет к добавлению атрибута в элемент img модуля Image, но именем атрибута будет квалифицированное имя, включая префикс, если для экземпляра документа выбрана префиксация. Кроме того, в список атрибутов элемента img будет добавлен атрибут xmlns:MODULE_PREFIX, так что синтаксические анализаторы с поддержкой пространства имен XML будут знать, как разрешить пространство имен в зависимости от префикса.
В следующем примере показано объявление подмодуля для гипотетического модуля Inventory.





<![%Inventory.prefixed;[
<!ENTITY % Inventory.xmlns.attrib
"%NS.decl.attrib;"
>
]]>
<!ENTITY % Inventory.xmlns.attrib
"xmlns %URI.datatype; #FIXED '%Inventory.xmlns;'"
>

<!ENTITY % Inventory.Common.attrib
"%Inventory.xmlns.attrib;
id ID #IMPLIED
>

<!ELEMENT %Inventory.shelf.qname;
( %Inventory.item.qname; )* >
<!ATTLIST %Inventory.shelf.qname;
location CDATA #IMPLIED
%Inventory.Common.attrib;
>
<!ELEMENT %Inventory.item.qname;
( %Inventory.desc.qname;, %Inventory.sku.qname;, %Inventory.price.qname;) >
<!ATTLIST %Inventory.item.qname;
location CDATA #IMPLIED
%Inventory.Common.attrib;
>
<!ELEMENT %Inventory.desc.qname; ( #PCDATA ) >
<!ATTLIST %Inventory.desc.qname;
%Inventory.Common.attrib;
>
<!ELEMENT %Inventory.sku.qname; ( #PCDATA ) >
<!ATTLIST %Inventory.sku.qname;
%Inventory.Common.attrib;
>
<!ELEMENT %Inventory.price.qname; ( #PCDATA ) >
<!ATTLIST %Inventory.price.qname;
%Inventory.Common.attrib;
>

Г.2.3. Использование модуля как автономного DTD
Иногда бывает нужно использовать модуль XHTML в качестве автономного DTD. Хорошим примером может служить описанный выше модуль Inventory. Должна существовать возможность внедрения этих элементов в документ XHTML, но кроме этого, они должны быть доступны как свободные документы, извлеченные из базы данных (например). Проще всего достичь этого путем определения файла DTD, инициализирующего компоненты модуля. Такое DTD может иметь следующую структуру:
Включите модуль XHTML Datatypes (обычно модуль qnames использует некоторых из этих типов данных - как минимум тип URI для атрибута xmlns).
Включите модуль Qnames для своего модуля.
Определите параметрическую сущность NS.decl.attrib как %MODULE.xmlns.extra.attrib;.
Включите модуль(и) Declaration для своего модуля.
Вот пример для нашего модуля Inventory:





<!ENTITY % xhtml-datatypes.mod
PUBLIC "-//W3C//ENTITIES XHTML Datatypes 1.0//EN"
"http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-datatypes-1.mod" >
%xhtml-datatypes.mod;

<!ENTITY % Inventory-qname.mod SYSTEM "inventory-qname-1.mod" >
%Inventory-qname.mod;
<!ENTITY % NS.decl.attrib "%Inventory.xmlns.extra.attrib;">
<!ENTITY % Inventory.mod SYSTEM "inventory-1.mod" >
%Inventory.mod;

Это DTD может использоваться в документах, в которых используются только элементы из вашего модуля:
<!DOCTYPE shelf SYSTEM "inventory-1.dtd">
<shelf xmlns="http://www.example.com/xmlns/inventory">
<item>
<desc>
это описание.
</desc>
<sku>
это цена.
</sku>
<price>
это цена.
</price>
</item>
</shelf>
Этот метод позволяет создавать определения элементов и атрибутов, областью действия которых является их собственное пространство имен. Кроме того, он позволяет разработчикам контента использовать префикс по умолчанию для элементов и атрибутов:
<!DOCTYPE inventory:shelf SYSTEM "inventory-1.dtd" [
<!ENTITY % Inventory.prefixed "INCLUDE">
]>
<inventory:shelf xmlns:inventory="http://www.example.com/xmlns/inventory">
<inventory:item>
<inventory:desc>
это описание.
</inventory:desc>
<inventory:sku>
это инвентарный номер.
</inventory:sku>
<inventory:price>
это цена.
</inventory:price>
</inventory:item>
</inventory:shelf>
И, наконец, в экземпляре документа может использоваться другой префикс пространства имен XML путем переобъявления в заголовке DOCTYPE и его внутреннем подмножестве:
<!DOCTYPE i:shelf SYSTEM "inventory-1.dtd" [
<!ENTITY % Inventory.prefixed "INCLUDE">
<!ENTITY % Inventory.prefix "i">
]>
<i:shelf xmlns:i="http://www.example.com/xmlns/inventory">
<i:item>
<i:desc>
это описание.
</i:desc>
<i:sku>
это цена.
</i:sku>
<i:price>
это цена.
</i:price>
</i:item>
</i:shelf>
Г.2.4. Отличительные особенности пространств имен
Хотя определенный здесь подход и дает возможность определения языков разметки, конформных XML и пространствам имен XML, некоторые возможности, определяемые в спецификации пространств имен XML, не поддерживаются:
Пространства имен XML позволяют повторно объявлять атрибут xmlns для пространства имен в любой точке дерева. Более того, они позволяют таким переобъявлением переключаться между использованием префиксов и пространства имен по умолчанию и изменять префикс. Метод, определенный в данном документе, не поддерживает эти возможности. В одном экземпляре документа одно пространство имен должно использовать один и тот же префикс (если используется префиксация) или область действия по умолчанию.
Если используется область действия по умолчанию, для информирования анализаторов о пространстве имен элемента допускается полагаться на DTD документа. Однако поскольку процессоры с поддержкой пространств имен не обязательно должны включать DTD при рассмотрении документа, разработчикам контента следует объявлять пространство имен XML элемента каждый раз при смене пространства имен:
...
<p>
<myelement xmlns="..." />
</p>
[назад] [далее] [содержание]
содержание | 2 | Ищем авторов

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