Модуляризация XHTML

Абстрактные Модули XHTML

Этот раздел является нормативным.
В этом разделе специфицировано содержимое абстрактных модулей XHTML. Эти модули являются абстрактными определениями коллекций элементов, атрибутов и их моделей содержимого. Эти абстрактные модули могут отображаться в любой подходящий механизм спецификации. , например, отображает эти модули в ОТД, как описано в .
Разработчикам содержимого и дизайнерам устройств необходимо просмотреть этот раздел как руководство по определению функциональности, предоставляемой различными модулями, определёнными XHTML.

При разработке документов или определении профиля для класса документов, разработчики содержимого смогут определить, который из этих модулей более всего подходит для них.

При разработке клиентов дизайнеры устройств должны разрабатывать профили своих устройств, выбирая абстрактные модули, определённые здесь.
За исключением переопределённых в этом документе, семантика элементов и атрибутов определена в .

Абстрактные модули

Тип документа XHTML определён как набор абстрактных модулей. Абстрактный модуль определяет один вид данных, семантически отличающихся от всех других. Абстрактный модуль может комбинироваться в типах документа без глубокого понимания основных схем определения модулей.

Аплет

applet.qname; %applet.content; > ]]>
]]>

Атрибут 'style'

Base/База

base.qname; %base.content; > ]]>
]]>

Базовая архитектура XHTML

Базовые формы

form.qname; %form.content; > ]]>

]]>

label.qname; %label.content; > ]]>

]]>

input.qname; %input.content; > ]]>

]]>

select.qname; %select.content; > ]]>

]]>

option.qname; %option.content; > ]]>

]]>

textarea.qname; %textarea.content; > ]]>

]]>

Базовые Таблицы

table.qname; %table.content; > ]]>

]]>

caption.qname; %caption.content; > ]]>

]]>

tr.qname; %tr.content; > ]]>

]]>

th.qname; %th.content; > ]]>

]]>

td.qname; %td.content; > ]]>

]]>

Блок Phrasal

address.qname; %address.content; > ]]>
]]>
blockquote.qname; %blockquote.content; > ]]>
]]>
pre.qname; %pre.content; > ]]>

]]>

h1.qname; %Heading.content; > ]]>

]]>

h2.qname; %Heading.content; > ]]>

]]>

h3.qname; %Heading.content; > ]]>

]]>

h4.qname; %Heading.content; > ]]>

]]>

h5.qname; %Heading.content; > ]]>

]]>

h6.qname; %Heading.content; > ]]>

]]>

Блок Presentational

hr.qname; %hr.content; > ]]>
]]>

Блок Structural

div.qname; %div.content; > ]]>
]]>
p.qname; %p.content; > ]]>
]]>

Цели дизайна

Содержание

H.1.

H.1.1.

H.1.2.

H.1.3.

H.1.4.

H.1.5.

Это приложение является информативным.
В этом приложении цели дизайна помечены лэйблом "Gn", а требования идентифицируются лэйблом "Rn.n".

Вот 4 главных целей дизайна для каркаса модуляризации XHTML:

[G1] Группировать семантические связанные части XHTML.

[G2] Использовать технологию ОТД (Определения Типа Документа) для поддержки создания связанных языков (поднаборов, наднаборов) специального назначения (портативные устройства, специальные устройства), гарантируя единство перекрывающихся частей.

[G3] Облегчать будущую разработку, давая возможность замещать части языка улучшенными модулями (например, формы) без нарушения оставшихся частей языка.

[G4] Поощрять и облегчать повторное использование модулей в других языках.

Что такое Модуляризация XHTML?

Модуляризация XHTML это разделение XHTML 1.0, относительно HTML 4, на коллекцию абстрактных модулей, которые предоставляют специфические типы функциональности. Эти абстрактные модули реализованы в данной спецификации с использованием языка XML Document Type Definition/Определения Типа Документа, но ожидается появление реализации с использованием Схемы XML.

Правила определения абстрактных модулей и реализации их с использованием ОТД XML также определены в данном документе.
Эти модули могут комбинироваться друг с другом и с другими модулями для создания поднабора и расширения типов документа XHTML, которые можно квалифицировать как членов семейства типов документов XHTML.

Что такое XHTML?

XHTML это переформулирование HTML 4 как приложения XML.
XHTML 1.0 специфицирует три типа документа XML, соответствующие трём ОТД (Определениям Типа Документа) HTML 4: Strict/Строгое, Transitional/Переходное и Frameset/Набор Фрэймов.
XHTML 1.0 является базой семейства типов документов, подразделяющих и расширяющих HTML.

Для чего нужна Модуляризация XHTML?

Модуляризация XHTML - это задача специфицирования правильно определённых наборов элементов XHTML, которые (наборы) могут комбинироваться и расширяться авторами документов, создателями типов документов, другими спецификациями стандартов XML и дизайнерами приложений и продуктов с целью дать техническую возможность разработчикам содержимого доставлять это содержимое на большое количество разнообразных платформ.
За последние два года многие специализированные рынки приняли HTML в качестве языка содержимого. Происходит быстрое продвижение в направлении использования HTML на большом количестве новых компьютерных платформ.

В настоящее время наблюдается активность в продвижении HTML на мобильные устройства (наручные компьютеры, портативные телефоны и т.п.), телевизионные устройства (цифровые телевизоры, Web-браузеры на базе TV и т.п.) и приборы (устройства с фиксированными функциями). Каждое из этих устройств имеет свои особые требования и ограничения.
Модуляризация XHTML предоставляет дизайнерам продуктов средства спецификации элементов, поддерживаемых устройством, с использованием стандартных строительных блоков и стандартных методов определения того, какие блоки используются.

Эти модули служат "точками соответствия" для сообщества содержимого. Сообщество содержимого может теперь иметь установленную базу, поддерживающую определённые коллекции модулей, вместо того, чтобы беспокоиться об установленной базе, которая поддерживает то или иное изменение элементов XHTML. Использование стандартов является критичным для того, чтобы модуляризованный XHTML имел успех повсюду. Для разработчиков содержимого экономически нереально подгонять содержимое к каждому изменению элементов XHTML. Путём спецификации стандарта, любой процесс программы может автономно создавать содержимое для устройства, или устройство может автоматически загрузить программу, необходимую для работы модуля.
Модуляризация позволяет также расширять возможности представления XHTML путём использования расширяемости XML без нарушения стандарта XHTML. Такой способ разработки даёт стабильную и реальную основу для разработчиков содержимого и издателей при обслуживании быстро множащихся технологических изменений на Web.

Дробность

Суммарно требования этого раздела можно выразить пожеланием - модули, определённые в каркасе, должны иметь высокий уровень дробности:

[R1.1] Абстрактные модули должны продвигать и обслуживать портативность содержимого.

[R1.2] Абстрактные модули должны продвигать стандартизацию профилей платформ.

[R1.3] Абстрактные модули должны достаточно большими, чтобы способствовать взаимодействию.

[R1.4] Абстрактные модули должны быть достаточно маленькими, чтобы исключить необходимость создания поднаборов.

[R1.5] Абстрактные модули должны объединять элементы со схожей или связанной семантикой.

[R1.6] Абстрактные модули должны разделять элементы с несхожей или несвязанной семантикой.

[R1.7] Модули должны быть достаточно маленькими, чтобы допускать модули одноэлементного типа документа.

Двунаправленный текст

bdo.qname; %bdo.content; > ]]>
]]>

F.Списки

dl.qname; %dl.content; > ]]>
]]>

dt.qname; %dt.content; > ]]>
]]>

dd.qname; %dd.content; > ]]>

]]>

ol.qname; %ol.content; > ]]>

]]>

ul.qname; %ul.content; > ]]>

]]>

li.qname; %li.content; > ]]>

]]>

Формы

form.qname; %form.content; > ]]>

]]>

label.qname; %label.content; > ]]>

]]>

input.qname; %input.content; > ]]>

]]>

select.qname; %select.content; > ]]>

]]>

optgroup.qname; %optgroup.content; > ]]>

]]>

option.qname; %option.content; > ]]>

]]>

textarea.qname; %textarea.content; > ]]>

]]>

fieldset.qname; %fieldset.content; > ]]>

]]>

legend.qname; %legend.content; > ]]>

]]>

button.qname; %button.content; > ]]>

]]>

Фрэймы

frameset.qname; %frameset.content; > ]]>
]]> ]]>

frame.qname; %frame.content; > ]]>

]]>

noframes.qname; %noframes.content; > ]]>

]]>

Гибридные типы документов

Гибридный тип документа это тип документа, составленный из коллекции ОТД XML или Модулей ОТД. Основным назначением Каркаса Модуляризации, описанного в данном документе, является: дать автору ОТД возможность сочетать элементы из нескольких абстрактных модулей в гибридный тип документа, разрабатывать документы относительно этого гибридного типа документов и легализовать эти документы относительно ассоциированного определения гибридного типа документа.
Одним из самых важных преимуществ XML по сравнению с SGML является то, что XML уменьшает препятствия на пути к стандартизации наборов элементов, что позволяет сообществам обмениваться данными в подходящем формате.

В то же время, относительно статичная природа HTML как языка содержимого Web означает, что любой член этих сообществ раньше имел мало надежд на то, что его типы документов XML могут быть широко приняты в качестве стандартов Web.

Каркас Модуляризации даёт возможность динамически сочетать эти разнообразные типы документов в типах документов семейства XHTML, устраняя в дальнейшем препятствия на пути включения этих зависящих от специфики домена словарей в документы XHTML.

Гипертекст

a.qname; %a.content; > ]]>
]]>

Идентификация имени

]]>
]]>
]]>
]]>
]]>
]]>
]]>

Идиосинкразии пространства имён

В то время как определённый здесь подход допускает определение языков разметки, соответствующих ПИ XML и XML, некоторые возможности, определённые спецификацией ПИ XML, не поддерживаются:
Пространство имён XML разрешает переобъявление атрибута xmlns для ПИ в любой точке дерева, а также разрешает при переобъявлении переключение между использованием ПИ по умолчанию и с префиксами и изменение префикса.

Метод, определённый в данном документе, этого не допускает. По всему объекту документа данное ПИ обязано использовать один и тот же префикс ПИ (если префиксирование используется) или обязано использоваться в области видимости по умолчанию.
При использовании значений по умолчанию ПИ XML верным будет основываться на ОТД документа для того, чтобы информировать разборщики о ПИ элементов. Однако, поскольку от процессоров, умеющих обрабатывать ПИ, не требуется включать ОТД при обсчёте документа, разработчики содержимого должны объявлять ПИ XML для элемента в тех случаях, когда ПИ изменяется:
...

[] [] []

Iframe

iframe.qname; %iframe.content; >

Именование объектов параметров

Эта спецификация классифицирует объекты параметров по семи категориям и именует их соответственно, используя следующие суффиксы:
.mod
объекты параметров используют суффикс .mod , если они используются для представления модуля ОТД (коллекции элементов, атрибутов, объектов параметров и т.д.). Каждый модуль в этой спецификации является атомарной единицей и может быть представлен как отдельный объект файла.
.module
объекты параметров используют суффикс .module , если они используются для управления включением модуля ОТД и содержат ключевое слово INCLUDE или IGNORE секции условий.
.qname
объекты параметров используют суффикс .qname , если они используются для представления квалифицированного имени элемента. См. дополнительно о квалифицированных именах .
.content
объекты параметров используют суффикс .content , если они используются для представления модели содержимого типа элемента.
.class
объекты параметров используют суффикс .class , если они используются для представления элементов одного класса.
.mix
объекты параметров используют суффикс .mix , если они используются для представления коллекции типов элементов из разных классов.
.attrib
объекты параметров используют суффикс .attrib , если они используются для представления группы лексем, представляющих одну или несколько полных спецификаций атрибутов с объявлением ATTLIST.
Например, в HTML 4 объект параметра %block; определён для представления разнородной коллекции типов элементов, которые являются элементами уровня блока. В этой спецификации результирующим объектом параметра является
%Block.mix;.
При определении объектов параметров в классах, определённых здесь, модули должны "видеть" имена объектов, используя уникальные префиксы. Например, модель содержимого для элемента myelement в модуле mymodule может быть именована MYMODULE.myelement.content. Возможны и другие схемы. Независимо от используемой схемы, авторы модулей должны удостовериться, что объекты параметров, которые они (авторы) определили, именованы уникально, что они не конфликтуют с другими объектами параметров и что методы интерфейса очевидны для пользователей.

Информативные ссылки

[MATHML]
"", W3C Recommendation, D. Carlisle, P. Ion, R. Miner, N. Poppelie,
eds., 21 февраля 2001.

Находится на http://www.w3.org/TR/2001/REC-MathML2-20010221
[SMIL]
"", W3C Recommendation, P. Hoschka, ed., 15 июня 1998.

Находится на http://www.w3.org/TR/1998/REC-smil-19980615
[XLINK]
"", W3C Proposed Recommendation, S. DeRose, E. Maler, D. Orchard, eds., 20 декабря 2000.

Находится на http://www.w3.org/TR/2000/PR-xlink-20001220
[XMLSTYLE]
"", W3C Recommendation, J. Clark,
ed., 29 июня 1999.

Находится на http://www.w3.org/TR/1999/REC-xml-stylesheet-19990629
[] [] []

Инлайн Phrasal

abbr.qname; %abbr.content; > ]]>
]]>
acronym.qname; %acronym.content; > ]]>
]]>
cite.qname; %cite.content; > ]]>

]]>

code.qname; %code.content; > ]]>

]]>

dfn.qname; %dfn.content; > ]]>

]]>

em.qname; %em.content; > ]]>

]]>

kbd.qname; %kbd.content; > ]]>

]]>

q.qname; %q.content; > ]]>

]]>

samp.qname; %samp.content; > ]]>

]]>

strong.qname; %strong.content; > ]]>

]]>

var.qname; %var.content; > ]]>

]]>

Инлайн Presentational

-->
b.qname; %b.content; > ]]>
]]>
big.qname; %big.content; > ]]>
]]>
i.qname; %i.content; > ]]>

]]>

small.qname; %small.content; > ]]>

]]>

sub.qname; %sub.content; > ]]>

]]>

sup.qname; %sup.content; > ]]>

]]>

tt.qname; %tt.content; > ]]>

]]>

Инлайн Structural

br.qname; %br.content; >
]]>
]]>

span.qname; %span.content; > ]]>
]]>

Интегрирование отдельных модулей в XHTML

Если модуль (помните, что модуль может быть коллекцией других модулей) содержит элементы, которые только ссылаются один на другой в своей модели содержимого, то говорят, что модуль "внутренне завершён". В связи с этим модуль может использоваться как таковой; (например, Вы можете определить ОТД, которое является этим модулем, и использовать один из его элементов в качестве корневого элемента). Интеграция такого модуля в XHTML - это процесс из трёх этапов:

Решите, какой(ие) элемент(ы) может быть корневым(и) в новом модуле.

Определите, где эти элементы необходимо подключить к дереву содержимого XHTML.

Затем для каждой точки подключения в дереве содержимого добавьте корневой элемент(ы) к определению содержимого элементов XHTML.

Рассмотрим подключение элементов, определённых .

Элемент myelement является корневым. Чтобы подключить этот элемент под элементом img, и только элементом img , в XHTML может сработать следующее:

ОТД, определённое с этой моделью содержимого, позволяет создать документ, подобный следующему фрагменту:

Это содержимое локально определённого элемента
Важно отметить, что обычно элемент img имеет модель содержимого EMPTY. Путём добавления myelement к этой модели содержимого мы в действительности просто заместили
EMPTY на myelement.

В случае с элементами, которые уже имеют определённые модели содержимого, добавление элемента может потребовать переобъявления существующей модели содержимого в дополнение к myelement.

Использование модуля как отдельного (stand-alone) ОТД

Иногда необходимо, чтобы модуль XHTML использовался также в качестве отдельного ОТД (Определения Типа Документа). Хорошим примером может служить вышеприведённый модуль Inventory. Его объекты должны быть внедряемы в документ XHTML и доступны как отдельные самостоятельные документы, извлечённые из базы данных (к примеру). Проще всего сделать это путём определения файла ОТД, который устанавливает компоненты Вашего модуля.

Подобное ОТД могло бы иметь такую структуру:

Включить модуль XHTML Datatypes (Ваш модуль qnames скорее всего использует некоторые из этих типов данных - он обычно использует тип данных URI для атрибута xmlns).

Включить модуль Qnames для Вашего модуля.

Определить объект параметра NS.decl.attrib как %MODULE.xmlns.extra.attrib;.

Включить модуль(и) Declaration для Вашего модуля.

Пример этого для нашего модуля Inventory приведён здесь:

%xhtml-datatypes.mod;
%Inventory-qname.mod;

%Inventory.mod;

На это ОТД могут затем ссылаться документы, которые используют только элементы из Вашего модуля:

this is a description. this is the price. this is the price.

Этот метод допускает определение элементов и атрибутов, находящихся в своём собственном пространстве имён. Он позволяет также разработчикам содержимого использовать префикс по умолчанию для элементов и атрибутов:

]> this is a description. this is the sku. this is the price.

Наконец, объект документа может использовать другой префикс пространства имён XML путём переобъявления его с внутренними поднаборами в шапке DOCTYPE:

]> this is a description. this is the price. this is the price.

Использование нового ОТД

После того как новое ОТД разработано, оно может быть использовано в любом документе. ОТД используется просто - ссылкой на него в объявлении DOCTYPE документа:
Пример, использующий значения по умолчанию.

Это содержимое пространства имён XHTML.

Это содержимое пространства имён SimpleML.

Missing image

Документ может также использовать элементы вне пространства имён XHTML путём присоединения к ним префиксов:
]> Пример, использующий значения по умолчанию.

Это содержимое пространства имён XHTML.

Это содержимое пространства имён myml.

Missing image

[] [] []

Изображения

img.qname; %img.content; > ]]>
]]>

Эволюция Модулей XHTML

Каждый модуль этой спецификации получил уникальный идентификатор, который соблюдает правила именования, описанные в предыдущем разделе. Со временем модули могут развиваться. Логическое разветвление при такой эволюции может привести к тому, что некоторые аспекты модуля уже не будут более совместимыми с предыдущим определением. Чтобы иметь уверенность, что типы документов, определённые относительно модулей, определённых в данной спецификации, продолжают работать, идентификаторы, ассоциированные с изменённым модулем, должны обновляться. В особенности Formal Public Identifier и System Identifier модуля будут изменяться путём модификации идентификатора версии. Типы документов, которые "хотят" быть внедрёнными в обновлённую функциональность, должны быть таким же образом обновлены.
В дополнение к этому, более ранняя версия(ии) модуля продолжат быть доступными через их более ранние уникальные идентификаторы. Таким образом, типы документов, разработанные с использованием модулей XHTML, продолжат функционирование, используя их оригинальные определения, даже при расширении и развитии коллекции. Таким же образом документы, написанные относительно существующих типов документов, останутся работоспособными, используя более ранние определения модулей.
Авторам других Модулей Семейства XHTML и Типов Документов рекомендуется применять сходную стратегию, чтобы быть уверенными, что функционирование типов документов на базе соответствующих модулей и объектов документов на базе этих типов документов продолжится.
[] [] []

Клиентские карты изображений

area.qname; %area.content; > ]]>

]]>

map.qname; %map.content; > ]]>

]]>

Коллекции атрибутов

Многие из абстрактных модулей этого раздела определяют необходимые атрибуты для элементов. Ниже дана таблица, в которой определены некоторые коллекции атрибутов, на которые имеются ссылки в модулях. Эти выражения никоим образом не должны рассматриваться как нормативные или мандатные. Они являются редакторским соглашением для данного документа. При использовании в данном разделе они служат расширением нормативного термина, но не самим термином.
Следующие базовые наборы атрибутов используются во многих элементах. При каждом их появлении, их использование идентифицируется именем коллекции, но не перечислением всего списка.

Название коллекции
Атрибуты коллекции

Core/Ядро	class (), id (), title ()
I18N	xml:lang ()
Events/События	onclick (), ondblclick (), onmousedown (), onmouseup (), onmouseover (), onmousemove (), onmouseout (Script), onkeypress (), onkeydown (), onkeyup ()
Style/Стиль	style ()
Common/Общая	+ + +

Обратите внимание, что коллекция Events определена только тогда, когда выбран модуль Intrinsic Events. Иначе коллекция Events является пустой.
Заметьте также, что коллекция Style определена только тогда, когда выбран модуль Style Attribute. Иначе коллекция Style является пустой.

Квалифицированные имена XHTML

]]>

%xhtml-qname-extra.mod;

]]>

]]>

%xhtml-qname.redecl;

Легализация

font.qname; %font.content; > ]]>

]]>

basefont.qname; %basefont.content; > ]]>

]]>

center.qname; %center.content; > ]]>

]]>

s.qname; %s.content; > ]]>

]]>

strike.qname; %strike.content; > ]]>

]]>

u.qname; %u.content; > ]]>

]]>

dir.qname; %dir.content; > ]]>

]]>

menu.qname; %menu.content; > ]]>

]]>

isindex.qname; %isindex.content; > ]]>

]]>

%xhtml-frames.mod;]]>

%xhtml-iframe.mod;]]>

Легализация

Использование правильно сформированных, но не легализованных документов, является важным преимуществом XML. В процессе разработки типа документа, однако, важно дополнительное преимущество, предоставляемое легализующим разборщиком при проверке ошибок. Один и тот же оператор применяется к типам документов XHTML с элементами из разных абстрактных модулей.
Документ является объектом особого типа документа, определённого в ОТД, идентифицированном в прологе документа. Легализация документа это процесс проверки того, выполняет ли документ правила определения типа документа.
Один документ может состоять из нескольких фрагментов. Легализация только этих фрагментов, где каждый фрагмент имеет отличный от других тип документа, находится вне специфики данной работы - поскольку это потребует технологий, ещё не разработанных.
Тем не менее, Каркас Модуляризации даёт возможность интегрировать несколько определений типов документов и формировать новый тип документа (напр., SVG, интегрированный в XHTML). Определение нового типа документов может использоваться для нормальной легализации XML 1.0.

Link/Ссылка

link.qname; %link.content; > ]]>
]]>

Лёгкость использования

Каркас модуляризации может только тогда широко применяться, когда он описывает механизмы, облегчающие использование каркаса целевой аудиторией:

[R3.1] Каркас модуля должен облегчать дизайнерам типа документа подразделение и расширение абстрактных модулей XHTML.

[R3.2] Каркас модуля должен облегчать дизайнерами типа документа создание абстрактных модулей для других типов документов XML.

[R3.3] Каркас модуля должен облегчать авторам документов проверку элементов из различных абстрактных модулей.

Метаинформация

meta.qname; %meta.content; > ]]>
]]>

Мнемоники символов XHTML

ОТД XHTML дают доступ к стандартной коллекции именованных символьных мнемоник. Эти мнемоники определены в данном разделе.

%xhtml-xlink.mod;

%xhtml-qname.mod;]]>

%xhtml-events.mod;]]>

%xhtml-attribs.mod;]]>

%xhtml-model.redecl;

%xhtml-model.mod;]]>

%xhtml-charent.mod;]]>

Заметьте, что вышеприведённый модуль относится к модулю модели содержимого. Этот модуль определён на базе типа per-document/документного в дополнение к файлу драйвера типа документа. Модульный каркас базируется также на следующих модулях компонентов:

Набор мнемоник, совместимых с XML

Мнемоники XHTML: математические, греческие и символические

Модель форматирования

Предыдущие версии HTML пытались определить части такой модели, которые требовались от пользовательского агента (ПА) для использования при форматировании документа. С появлением HTML 4, W3C начал процесс отделения представления от структуры. XHTML 1.0 поддерживает это разделение, и данный документ продолжает движение от HTML и его потомков в этом направлении. Соответственно, данный документ не выдвигает никаких требований к модели форматирования, ассоциированной с представлением документов, размеченных с помощью типов документов Семейства XHTML.
Наоборот, данный документ рекомендует, чтобы авторы содержимого полагались на механизмы определения стилей, такие как CSS, при определении модели форматирования для своего содержимого.

Если ПА поддерживают механизмы стилей, то документы будут сформатированы так, как ожидается.

Если ПА не поддерживают механизмы стилей, то документы будут сформатированы так, как определяет сам ПА. Это позволяет ПАгентам Семейства XHTML поддерживать сложные (так и просится - навороченные; А.Р.) модели форматирования на тех устройствах, где это возможно, и изменять модели форматирования на тех устройствах, где это
допустимо.
[] [] []

Модуль Applet

Не рекомендуется применять этот модуль. Соответствующая функциональность может быть найдена в .
Модуль Applet предоставляет элементы для ссылок на внешние приложения.

Модуль Applet поддерживает следующие элементы и атрибуты:

Элементы
Атрибуты
Модель минимального содержимого

applet	Core, alt* (), archive (), code (), codebase (), height* (), object (), width* ()	(PCDATA \| Flow \| param)*
param	id (), name* (), type (ContentType), value (), valuetype ("data"* \| "ref" \| "object")	EMPTY

При использовании модуля Applet добавляется элемент applet к набору содержимого Inline модуля Text.
Реализация:

Модуль Base

В модуле Base определён элемент, который может использоваться для определения базового URI, с помощью которого вычисляются относительные URI документа.

Элемент и атрибут этого модуля:

Элемент
Атрибут
Модель минимального содержимого

base

href* ()

EMPTY

При использовании этого модуля элемент base добавляется к модели содержимого элемента head модуля Structure.
Реализация:

Модуль Basic Forms

Модуль Basic Forms предоставляет элементы, относящиеся к форме, но лишь в ограниченном виде. Модуль Basic Forms поддерживает следующие элементы, атрибуты и модель минимального содержимого:

Элементы
Атрибуты
Модель минимального содержимого

form	, action* (), method ("get"* \| "post"), enctype ()	(Heading \| List \| Block - form)+
input	, accesskey (), checked ("checked"), maxlength (), name (), size (), src (), tabindex (), type ("text"* \| "password" \| "checkbox" \| "radio" \| "submit" \| "reset" \| "hidden" ), value ()	EMPTY
label	, accesskey (), for ()	(PCDATA \| Inline - label)*
select	, multiple ("multiple"), name (), size (), tabindex ()	option+
option	, selected ("selected"), value ()	PCDATA
textarea	, accesskey (), cols* (), name (), rows* (), tabindex ()	PCDATA

Модуль определяет два набора содержимого:
Form
form
Formctrl
input | label | select | textarea
При использовании этого модуля добавляется набор содержимого Form к набору содержимого Block и набор содержимого Formctrl к набору содержимого Inline, как это определено в модуле Text.
Реализация:

Модуль Basic Tables

Модуль Basic Tables предоставляет элементы, относящиеся к таблицам, но в ограниченном виде. Модуль Basic Tables поддерживает:

Элементы
Атрибуты
Модель минимального содержимого

caption		(PCDATA \| Inline)*
table	, summary ( ), width ( )	caption?, tr+
td	, abbr (), align ("left" \| "center" \| "right"), axis (), colspan (), headers (), rowspan (), scope ("row" \| "col"), valign ("top" \| "middle" \| "bottom")	(PCDATA \| Flow - table)*
th	, abbr (), align ("left" \| "center" \| "right"), axis (), colspan (), headers (), rowspan (), scope ("row" \| "col" ), valign ("top" \| "middle" \| "bottom")	(PCDATA \| Flow - table)*
tr	, align ("left" \| "center" \| "right"), valign ("top" \| "middle" \| "bottom")	(td \| th)+

При использовании этого модуля добавляется элемент table к набору содержимого Block, как определено в модуле Text.
Реализация:

Модуль Bi-directional Text

Модуль Bi-directional Text определяет элемент, который может использоваться для объявления правил двунаправленного текста для содержимого элемента.

Элемент
Атрибут
Модель минимального содержимого

bdo

, dir* ("ltr" | "rtl")

(PCDATA | Inline)*

При использовании этого модуля добавляется элемент bdo к набору содержимого Inline модуля Text. При выборе этого модуля добавляется также атрибут dir* ("ltr" | "rtl") к коллекции атрибутов I18N.
Реализация:

Модуль Client-side Image Map

Модуль Client-side Image Map предоставляет элементы для клиентских карт изображений. Для этого необходимо, чтобы модуль Image (или другой модуль, поддерживающий элемент img) был подключён. Модуль Client-side Image Map поддерживает следующие элементы:

Элементы
Атрибуты
Модель минимального содержимого

a&	coords (), shape ("rect" \| "circle" \| "poly" \| "default")	n/a
area	, accesskey (), alt* (), coords (), href (), nohref ("nohref"), shape ("rect"* \| "circle" \| "poly" \| "default"), tabindex ()	EMPTY
img&	usemap ()	n/a
input&	usemap ()	n/a
map	, , class (), id* (), title ()	((Heading \| Block) \| area)+
object&	usemap ()	Примечание: Только если подключён объектный модуль (object module).

При использовании этого модуля добавляется элемент map к набору содержимого Inline модуля Text.
Реализация:

Модуль Edit

Этот модуль определяет элементы и атрибуты для использования в разметке, относящейся к редактированию:

Элемент
Атрибуты
Модель минимального содержимого

del	, cite (), datetime (Datetime)	(PCDATA \| Flow)*
ins	, cite (), datetime (Datetime)	(PCDATA \| Flow)*

При использовании этого модуля добавляются элементы del и ins к набору содержимого Inline модуля Text.
Реализация:

Модуль Forms

Модуль Forms форм HTML 4.0. Модуль Forms поддерживает:

Элементы
Атрибуты
Модель минимального содержимого

form	, accept (), accept-charset (), action* (), method ("get"* \| "post"), enctype ()	(Heading \| List \| Block - form \| fieldset)+
input	, accept (), accesskey (), alt (), checked ("checked"), disabled ("disabled"), maxlength (), name (), readonly ("readonly"), size (), src (), tabindex (), type ("text"* \| "password" \| "checkbox" \| "button" \| "radio" \| "submit" \| "reset" \| "file" \| "hidden" \| "image"), value ()	EMPTY
select	, disabled ("disabled"), multiple ("multiple"), name (), size (), tabindex ()	(optgroup \| option)+
option	, disabled ("disabled"), label (), selected ("selected"), value ()	PCDATA
textarea	, accesskey (), cols* (), disabled ("disabled"), name (), readonly ("readonly"), rows* (), tabindex ()	PCDATA
button	, accesskey (), disabled ("disabled"), name (), tabindex (), type ("button" \| "submit"* \| "reset"), value ()	(PCDATA \| Heading \| List \| Block - Form \| Inline - Formctrl)*
fieldset		(PCDATA \| legend \| Flow)*
label	, accesskey (), for ()	(PCDATA \| Inline - label)*
legend	, accesskey ()	(PCDATA \| Inline)+
optgroup	, disabled ("disabled"), label* ()	option+

Этот модуль определяет два набора содержимого:
Form
form | fieldset
Formctrl
input | select | textarea | label | button
При использовании этого модуля добавляется набор содержимого Form к набору содержимого Block и набор содержимого Formctrl к набору содержимого Inline, как это определено в модуле Text.
Модуль Forms является наднабором модуля Basic Forms. Эти модули не могут использоваться совместно в одном типе документа.
Реализация:

Модуль Frames

Как видно из названия, модуль Frames предоставляет элементы относящиеся к фрэймам.

Модуль Frames поддерживает:

Элементы
Атрибуты
Модель минимального содержимого

frameset	, cols ( ), rows ( )	(frameset \| frame)+, noframes?
frame	, frameborder ("1" \| "0"), longdesc ( ), marginheight ( ), marginwidth ( ), noresize ("noresize"), scrolling ("yes" \| "no" \| "auto"*), src ( )	EMPTY
noframes		body

При использовании этого модуля модель минимального содержимого элемента html модуля Structure изменяется на (head, frameset).
Реализация:

Модуль Hypertext

Модуль Hypertext предоставляет элемент, который используется для определения гипертекстовых ссылок на другие ресурсы. Этот модуль поддерживает следующие элемент и атрибуты:

Элемент
Атрибуты
Модель минимального содержимого

, accesskey (), charset (),

href (), hreflang (), rel (),

rev (), tabindex (), type ()

(PCDATA | Inline - a)*

Этот модуль добавляет элемент a к набору содержимого Inline модуля Text.
Реализация:

Модуль Iframe

Модуль Iframe Module определяет элемент для определения инлайн-фрэймов.

Элемент и атрибуты этого модуля:

Элемент
Атрибуты
Модель минимального содержимого

iframe

, frameborder ("1" | "0"), height (), longdesc (), marginheight (), marginwidth (), scrolling ("yes" | "no" | "auto"*), src (), width ()

(PCDATA | Flow)*

При использовании этого модуля добавляется элемент iframe к набору содержимого Inline, как определено в модуле Text.
Реализация:

Модуль Image

Модуль Image предоставляет базовые возможности внедрения изображений и может независимо использоваться в некоторых реализациях клиентскими картами изображений. Модуль Image поддерживает следующие элемент и атрибуты:

Элемент
Атрибуты
Модель минимального содержимого

img

, alt* (), height (Length), longdesc (), src* (), width ()

EMPTY

При использовании этого модуля добавляется элемент img к набору содержимого Inline модуля Text.
Реализация:

Модуль Intrinsic Events

Внутренние события это атрибуты, используемые вместе с элементами, которые могут вызывать специфические события при выполнении пользователем определённых действий. Атрибуты, приведённые в следующей таблице, добавлены к набору атрибутов соответствующих элементов, если только
модули, определяющие эти элементы, подключены (выбраны). Заметьте также, что выбор этого модуля определяет коллекцию атрибутов , как описано выше. Атрибуты, определённые в этом модуле:

Элементы
Атрибуты
Примечания

a&	onblur (), onfocus ()
area&	onblur (), onfocus ()	Если используется также и модуль Client-side Image Map.
frameset&	onload (), onunload ()	Если используется также и модуль Frames.
form&	onreset (), onsubmit ()	Если используется модуль Basic Forms или Forms.
body&	onload (), onunload ()
label&	onblur (), onfocus ()	Если используется модуль Forms.
input&	onblur (), onchange (), onfocus (), onselect ()	Если используется модуль Basic Forms или Forms.
select&	onblur (), onchange (), onfocus ()	Если используется модуль Basic Forms или Forms.
textarea&	onblur (), onchange (), onfocus (), onselect ()	Если используется модуль Basic Forms или Forms.
button&	onblur (), onfocus ()	Если используется модуль Forms.

Реализация:

Модуль Legacy

Модуль Legacy определяет элементы и атрибуты, которые уже не рекомендовались в предыдущих версиях HTML и XHTML и остаются таковыми и в Модуляризации XHTML. Авторы языков разметки более не должны использовать эти элементы и атрибуты.
В следующей таблице приведены элементы и атрибуты, определяемые при выборе модуля Legacy.

Элементы
Атрибуты
Модель минимального содержимого

basefont	color (), face (), id (), size ()	EMPTY
center		(PCDATA \| Flow)*
dir	, compact ("compact")	(li)+
font	, , color (), face (), size ()	(PCDATA \| Inline)*
isindex	, , prompt ()	EMPTY
menu	, compact ("compact")	(li)+
s		(PCDATA \| Inline)*
strike		(PCDATA \| Inline)*
u		(PCDATA \| Inline)*

В следующей таблице показаны дополнительные атрибуты для элементов, определённых в любом другом месте, при выборе модуля Legacy.

Элементы
Атрибуты
Примечания

body&	alink (), background (), bgcolor (), link (), text (), vlink ()
br&	clear ("left" \| "all" \| "right" \| "none"*)
caption&	align ("top" \| "bottom" \| "left" \| "right")
div&	align ("left" \| "center" \| "right" \| "justify")
dl&	compact ("compact"), type ()
h1-h6&	align ("left" \| "center" \| "right" \| "justify")
hr&	align ("left" \| "center" \| "right" \| "justify"), (""), size (), width (),
img&	align ("left" \| "center" \| "right" \| "justify"), border (), hspace (), vspace ()
input&	align ("top" \| "middle" \| "bottom" \| "left" \| "right")	Если выбран модуль Basic Forms или Forms.
legend&	align ("left" \| "center" \| "right" \| "justify")	Если выбран модуль Forms.
li&	type (), value ()
ol&	compact ("compact"), start (), type ()
p&	align ("left" \| "center" \| "right", "justify")
pre&	width ()
script&	language ()	Если выбран модуль Scripting.
table&	align ("left" \| "center" \| "right"), bgcolor ()	Если выбран модуль Tables.
tr&	bgcolor ()	Если выбран модуль Tables.
th&	bgcolor (), height () nowrap ("nowrap"), width ()	Если выбран модуль Tables.
td&	bgcolor (), height () nowrap ("nowrap"), width ()	Если выбран модуль Tables.
ul&	compact ("compact"), type ()

Реализация:
[] [] []

Модуль Link

Модуль Link определяет элемент, который может использоваться для определения ссылок на внешние ресурсы. Эти ресурсы часто используются для расширения возможностей ПА при обработке ассоциированного документа XHTML.

Элемент и атрибуты этого модуля:

Элемент
Атрибуты
Модель минимального содержимого

link

, charset (), href (), hreflang (), media (MediaDesc), rel (), rev (), type ()

EMPTY

При использовании этого модуля элемент link добавляется к модели содержимого элемента head модуля Structure.
Реализация:

Модуль List

Как видно из названия, модуль List предоставляет элементы, ориентированные на списки.

Модуль List поддерживает следующие элементы и атрибуты:

Элементы
Атрибуты
Модель минимального содержимого

dl		(dt \| dd)+
dt		(PCDATA \| Inline)*
dd		(PCDATA \| Flow)*
ol		li+
ul		li+
li		(PCDATA \| Flow)*

Этот модуль определяет также набор содержимого List с минимальной моделью содержимого (dl | ol | ul)+ и добавляет этот набор к набору содержимого Flow модуля Text.
Реализация:

Модуль Metainformation

В модуле Metainformation определён элемент, описывающий информацию в объявляющей части документа (в XHTML - в элементе head).

Этот модуль содержит следующий элемент:

Элемент
Атрибуты
Модель минимального содержимого

Модуль Name Identification

Не рекомендуется применять этот модуль.
Модуль Name Identification определяет атрибут name для коллекции элементов. Атрибут name исторически использовался для идентификации определённых элементов в документах HTML. Поскольку атрибут name был вытеснен атрибутом id во всех этих элементах, могут быть варианты, когда языки разметки будут поддерживать оба эти атрибута. Такие языки разметки могут делать это путём включения данного модуля.
Обратите внимание, что при включении этого модуля оба атрибута - name и id - определены для указанных элементов. В такой ситуации, если для элемента определён атрибут name, атрибут id также должен быть определён. Кроме того, оба эти атрибута обязаны иметь одно и то же значение. Наконец, если документы, использующие этот атрибут, обрабатываются как Internet Media Type "text/xml" или "application/xml", то значение атрибута name в этих элементах не должно использоваться как идентификатор фрагмента.

Элементы
Атрибуты
Примечания

a&	name ()
applet&	name ()	Если выбран модуль Applet.
form&	name ()	Если выбран модуль Forms или Basic Forms.
frame&	name ()	Если выбран модуль Frames.
iframe&	name ()	Если выбран модуль Iframe.
img&	name ()	Если выбран модуль Image.
map&	name ()	Если выбран модуль Client-side Image Map.

Реализация:

Модуль Object

Модуль Object предоставляет поддержку включения объектов общего назначения.

Модуль Object поддерживает:

Элементы
Атрибуты
Модель минимального содержимого

object	Common, archive (), classid (), codebase (), codetype (), data (URI), declare ("declare"), height (), name (), standby (), tabindex (), type (), width ()	(PCDATA \| Flow \| param)*
param	id (), name* (), type (ContentType), value (), valuetype ("data"* \| "ref" \| "object")	EMPTY

При использовании этого модуля добавляется элемент object к набору содержимого Inline модуля Text.
Реализация:

Модуль Presentation

Этот модуль определяет элементы, атрибуты и модель минимального содержимого для простой разметки, относящейся к представлению:

Элементы
Атрибуты
Модель минимального содержимого

b		(PCDATA \| Inline)*
big		(PCDATA \| Inline)*
hr		EMPTY
i		(PCDATA \| Inline)*
small		(PCDATA \| Inline)*
sub		(PCDATA \| Inline)*
sup		(PCDATA \| Inline)*
tt		(PCDATA \| Inline)*

При использовании этого модуля добавляется элемент hr к набору содержимого Block модуля Text. Дополнительно добавлены элементы b, big, i, small, sub, sup и tt к набору содержимого Inline модуля Text.
Реализация:

Модуль Scripting

В модуле Scripting определены элементы, используемые для размещения информации, относящейся к выполняемым скриптам, или при отсутствии поддержки выполняемых скриптов. Элементы и атрибуты этого модуля:

Элементы
Атрибуты
Модель минимального содержимого

noscript		(Heading \| List \| Block)+
script	charset (), defer ("defer"), src (), type* (), xml:space="preserve"	PCDATA

При использовании этого модуля элементы script
и noscript добавляются к наборам содержимого Block и Inline модуля Text. Дополнительно элемент script добавляется к модели содержимого элемента head , определённого в модуле Structure.
Реализация:

Модуль Server-side Image Map

Модуль Server-side Image Map предоставляет поддержку выбора изображения и передачу координат выбора. Для этого необходимо, чтобы модуль Image (или другой модуль, поддерживающий элемент img) был подключён.

Модуль Server-side Image Map поддерживает следующие атрибуты:

Элементы
Атрибуты
Модель минимального содержимого
Примечания

img&	ismap ("ismap")	n/a
input&	ismap ("ismap")	n/a	Если выбран модуль Forms или Basic Forms.

Реализация:

Модуль Structure

Модуль Structure определяет основные структурные элементы XHTML. Эти элементы действуют эффективно как базис для модели содержимого многих типов документов семейства XHTML. Элементы и атрибуты, включённые в этот модуль:

Элементы
Атрибуты
Модель минимального содержимого

body		(Heading \| Block \| List)*
head	, profile ()	title
html	, version (), xmlns (URI = "http://www.w3.org/1999/xhtml")	head, body
title		PCDATA

Этот модуль является базовым структурным определением содержимого XHTML.

Элемент html действует как корневой элемент для всех Типов Семейства Документов XHTML.
Обратите внимание, что значение атрибута xmlns определено в "".

Также отметьте, что, поскольку атрибут xmlns рассматривается разборщиком пространства имён XML особым образом [], правильным будет вставлять его в качестве атрибута в каждый элемент. Однако всякий раз, когда атрибут xmlns используется в контексте модуля XHTML, с префиксом или без него, значением атрибута должно быть пространство имён XHTML, определённое здесь. См. дополнительные правила, относящиеся к использованию пространства имён с модулями семейства XHTML в .
Реализация:

Модуль Style Attribute

Модуль Style Attribute определяет атрибут style. Если выбран этот модуль, то он активирует .
Реализация:

Модуль Style Sheet

Модуль Style Sheet определяет элемент для использования при объявлении внедрённых таблиц стилей. Элемент и атрибуты этого модуля:

Элемент
Атрибуты
Модель минимального содержимого

style

, media (), title (),

type* (), xml:space="preserve"

PCDATA

При использовании этого модуля элемент style
добавляется к модели содержимого элемента head модуля Structure.
Реализация:

Модуль Tables

Как видно уже из названия, модуль Tables предоставляет элементы, которые относятся к таблицам и имеют улучшенный доступ из невизуальных ПА (пользовательских агентов). Модуль Tables поддерживает следующие элементы, атрибуты и модель содержимого:

Элементы
Атрибуты
Модель минимального содержимого

caption		(PCDATA \| Inline)*
table	, border (), cellpadding (), cellspacing (), datapagesize (), frame ("void" \| "above" \| below" \| "hsides" \| "lhs" \| "rhs" \| "vsides" \| "box" \| "border"), rules ("none" \| "groups" \| "rows" \| "cols" \| "all"), summary (), width ()	caption?, ( col* \| colgroup* ), (( thead?, tfoot?, tbody+ ) \| ( tr+ ))
td	, abbr (), align ("left" \| "center" \| "right" \| "justify" \| "char"), axis (), char (), charoff (), colspan (), headers (), rowspan (), scope ("row", "col", "rowgroup", "colgroup"), valign ("top" \| "middle" \| "bottom" \| "baseline")	(PCDATA \| Flow)*
th	, abbr (), align ("left" \| "center" \| "right" \| "justify" \| "char"), axis (), char (), charoff (), colspan (), headers (), rowspan (), scope ("row", "col", "rowgroup", "colgroup"), valign ("top" \| "middle" \| "bottom" \| "baseline")	(PCDATA \| Flow)*
tr	, align ("left" \| "center" \| "right" \| "justify", "char"), char (), charoff (), valign ("top" \| "middle" \| "bottom" \| "baseline")	(td \| th)+
col	, align ("left" \| "center" \| "right" \| "justify", "char"), char (), charoff (), span (), valign ("top" \| "middle" \| "bottom" \| "baseline"), width ()	EMPTY
colgroup	, align ("left" \| "center" \| "right" \| "justify", "char"), char (), charoff (), span (), valign ("top" \| "middle" \| "bottom" \| "baseline"), width ()	col*
tbody	, align ("left" \| "center" \| "right" \| "justify", "char"), char (), charoff (), valign ("top" \| "middle" \| "bottom" \| "baseline")	tr+
thead	, align ("left" \| "center" \| "right" \| "justify", "char"), char (), charoff (), valign ("top" \| "middle" \| "bottom" \| "baseline")	tr+
tfoot	, align ("left" \| "center" \| "right" \| "justify", "char"), char (), charoff (), valign ("top" \| "middle" \| "bottom" \| "baseline")	tr+

Модуль Target

Содержимое фрэйма может специфицировать цели назначения при выборе. Этот модуль добавляет элемент target к области и связывает определяемые элементы. Определяется отдельный модуль, поэтому он может быть включён в документы, которые входят в состав фреймов, и документы, использующие target для открытия нового окна.

Элементы
Атрибуты
Примечания

a&	target ( )
area&	target ( )	Если выбран модуль Client-side Image Map.
base&	target ( )	Если выбран модуль Legacy.
link&	target ( )	Если выбран модуль Link .
form&	target ( )	Если выбран модуль Basic Forms или Forms.

Реализация:

Модуль Text

Этот модуль определяет все базовые элементы-контейнеры, атрибуты текста и их модель содержимого:

Элемент
Атрибуты
Модель минимального содержимого

abbr		(PCDATA \| Inline)*
acronym		(PCDATA \| Inline)*
address		(PCDATA \| Inline)*
blockquote	, cite ()	(PCDATA \| Heading \| Block \| List)*
br		EMPTY
cite		(PCDATA \| Inline)*
code		(PCDATA \| Inline)*
dfn		(PCDATA \| Inline)*
div		(PCDATA \| Flow)*
em		(PCDATA \| Inline)*
h1		(PCDATA \| Inline)*
h2		(PCDATA \| Inline)*
h3		(PCDATA \| Inline)*
h4		(PCDATA \| Inline)*
h5		(PCDATA \| Inline)*
h6		(PCDATA \| Inline)*
kbd		(PCDATA \| Inline)*
p		(PCDATA \| Inline)*
pre	, xml:space="preserve"	(PCDATA \| Inline)*
q	, cite ()	(PCDATA \| Inline)*
samp		(PCDATA \| Inline)*
span		(PCDATA \| Inline)*
strong		(PCDATA \| Inline)*
var		(PCDATA \| Inline)*

Минимальная модель содержимого для этого модуля определяет несколько наборов содержимого:
Heading
h1 | h2 | h3 | h4 | h5 | h6
Block
address | blockquote | div | p | pre
Inline
abbr | acronym | br | cite | code | dfn | em | kbd | q | samp | span | strong | var
Flow
Heading | Block | Inline
Реализация:

Модуль XHTML Skiing

Модуль XHTML Skiing определяет разметку для использования при описании аспектов ski lodge (лыжного домика?? - кто знает, переведите!!). Элементы и атрибуты, определённые в этом модуле:

Элементы
Атрибуты
Модель минимального содержимого

resort	Common, href (CDATA)	description, Aspen+
lodge	Common	description, (Aspen - lift)+
lift	Common, href	description?
chalet	Common, href	description?
room	Common, href	description?
lobby	Common, href	description?
fireplace	Common, href	description?
description	Common	PCDATA*

Модули ядра

Модули ядра это модули, наличие которых необходимо в любом .

Модули поддержки ОТД XHTML

Модули этого раздела являются элементами реализации ОТД XHTML, которые, будучи скрытыми от случайного доступа, важны для понимания при создании языков производной разметки с использованием архитектуры Модуляризации.

Модули текстовых расширений

В этом разделе определены различные дополнительные модули текстовой разметки.

Модульный каркас XHTML

Чтобы использовать преимущества модуля ОТД XHTML, авторам ОТД необходимо определить модель содержимого для своих ОТД. XHTML предоставляет различные утилиты для облегчения этой работы. Это определено в наборе вспомогательных модулей в главном модуле Framework:

%xhtml-arch.mod;]]>
%xhtml-notations.mod;]]>
%xhtml-datatypes.mod;]]>

Нормативные ссылки

[CSS2]
"", W3C Recommendation, B. Bos, H. W. Lie, C. Lilley, I. Jacobs,
eds., 12 мая 1998.

Находится на http://www.w3.org/TR/1998/REC-CSS2-19980512
[DOM]
"", L. Wood et al., 1 октября 1998.

Находится на http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001
[HTML4]
"", W3C Recommendation, D. Raggett, A. Le Hors, I. Jacobs, eds., 24 декабря 1999.

Находится на http://www.w3.org/TR/1999/REC-html401-19991224
[ISO10646]
"Information Technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane", ISO/IEC 10646-1:2000. Это справочник о наборе кодовых точек, который дополняется по мере внесения в него новых символов. Также этот справочник принимает, что наборы символов, определённые в ISO 10646 и , являются эквивалентом символ-символ. Данный справочник содержит также будущие публикации других частей 10646 (т.е. не Part 1), определяющие символы в планах 1-16.
[RFC1808]
"", RFC 1808, R. Fielding, июнь 1995.

Находится на http://www.ietf.org/rfc/rfc1808.txt
[RFC2045]
"", RFC 2045, N. Freed, N. Borenstein, ноябрь 1996.

Находится на http://www.ietf.org/rfc/rfc2045.txt
[RFC2119]
"", RFC 2119, S. Bradner, март 1997.

Находится на http://www.ietf.org/rfc/rfc2119.txt
[RFC3066]
"", RFC 3066, H. Alvestrand, январь 2001.

Находится на http://www.ietf.org/rfc/rfc3066.txt
[SGML]
"Information Processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML)", ISO 8879:1986.

См. в информацию о стандарте или о SGML.
[SRGB]
"", version 1.10, M. Stokes, M. Anderson, S. Chandrasekar, and R. Motta, 5 ноября 1996.

Находится на http://www.w3.org/Graphics/Color/sRGB
[UNICODE]
"The Unicode Standard", The Unicode Consortium. Version 3.1 of the Unicode Standard составлен как книга, документирующая version 3.0 и онлайновое Unicode Standard Annex, документирующее изменения и дополнения, составляющие version 3.1.

"", The Unicode Consortium, Reading, Mass.: Addison- Wesley Developers Press, 2000. ISBN 0-201-61633-5 (см. в http://www.unicode.org/unicode/uni2book/u2.html online-издания книги).

"", Mark Davis, Michael Everson, Asmus Freytag, John H. Jenkins et al. (см. http://www.unicode.org/unicode/reports/tr27/).

О Unicode см. дополнительно .

[URI]

"", RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, август 1998.

Находится на http://www.ietf.org/rfc/rfc2396.txt. Это RFC обновляет RFC 1738 [URL]

и [RFC1808].

[URL]

"", RFC 1738, T. Berners-Lee, L. Masinter, M. McCahill, декабрь 1994.

Находится на http://www.ietf.org/rfc/rfc1738.txt

[XHTML1]

"", W3C Recommendation, S. Pemberton et al., 26 января 2000.

Находится на http://www.w3.org/TR/2000/REC-xhtml1-20000126

[XML]

"", W3C Recommendation, T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, eds., 6 октября 2000.

Находится на http://www.w3.org/TR/2000/REC-xml-20001006

[XMLNAMES]

"", W3C Recommendation, T. Bray, D. Hollander, A. Layman, eds., 14 января 1999.

Находится на http://www.w3.org/TR/1999/REC-xml-names-19990114

[XMLSCHEMA]

"", W3C Proposed Recommendation, H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn,

eds., 30 марта 2001.

Находится на http://www.w3.org/TR/2001/PR-xmlschema-1-20010330

См. также "",

Находится на

Нотация XHTML

Объект

object.qname; %object.content; > ]]>
]]>

Определение Абстрактных Модулей

4.1.

4.2.

4.3.

4.4.

4.4.1.

Определение дополнительных атрибутов

Определение дополнительных элементов

Определение коллекции содержимого для коллекции модулей

Переопределить объект параметра ".content" для каждого элемента.

Переопределить один или более объектов глобальной модели содержимого (обычно через объект параметра ".extras").

Определение пространства имён модуля

Определение соответствия

Содержание

3.2.

3.3.

3.4.

3.5.

3.6.

3.7.

Определения общих атрибутов XHTML

Param

Переобъявления наследственности

Подмодуль(и) объявлений

Определить объект параметра для использования с ATTLIST каждого объявленного элемента. Этот объект параметра должен содержать %NS.decl.attrib;, если %MODULE.prefixed; установлен в INCLUDE, и %NS.decl.attrib; плюс "xmlns %URI.datatype; #FIXED '%MODULE.xmlns;'", если %MODULE.prefixed; установлен в IGNORE.

Объявить все элементы и атрибуты модуля. В каждый ATTLIST элемента включить объект параметра, определённый выше, так, чтобы все необходимые атрибуты xmlns были доступны каждому элементу модуля.

Здесь должен быть добавлен атрибут к элементу img модуля Image, но имя атрибута будет квалифицированным именем, включая префикс, если префиксы выбраны для объекта документа.

Добавляется также атрибут xmlns:MODULE_PREFIX к списку атрибутов элемента img, так что разборщик, понимающий пространство имён XML, будет "знать", как разбирать пространство имён на безе его (ПИ) префиксов.
В следующем примере показано объявление подмодуля для гипотетического модуля Inventory:

]]>

Подмодуль Qualified Names/Квалифицированные Имена

Сначала Вам нужно определить подмодуль квалифицированных имён (подмодуль это обычный файловый объект, который отделён таким образом, что он может быть вставлен в результирующее ОТД в соответствующей точке). Подмодуль квалифицированных имён конструируется с прохождением следующих этапов (где строка MODULE заменена на соответствующую строку нового модуля):

Определить объект параметра MODULE с префиксом, извещающим о том, используются ли элементы модуля с именами с префиксами ПИ XML, или нет. Значение по умолчанию этого объекта параметра должно быть "%NS.prefixed;". Объект параметра NS.prefixed определён каркасом XHTML как IGNORE по умолчанию и может использоваться в объекте документа для запуска (switch on) префиксирования для всех включённых пространств имён (в том числе и ПИ модулей XHTML).

Определить объект параметра MODULE.xmlns, содержащий идентификатор ПИ для этого модуля.

Определить объект параметра MODULE.prefix, содержащий строку префикса по умолчанию для использования при запущенном префиксировании (enabled).

Определить объект параметра 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" - в противном случае.

Если модуль добавляет атрибуты к элементам, определённым в модуле, не разделяющем (share) ПИ данного модуля, объявите эти атрибуты так, чтобы они использовали префикс %MODULE.pfx. Например:

Пример подмодуля qname для гипотетического Inventory Module приведён ниже:

]]>

]]>

Построение модулей Схемы

Это приложение является нормативным.
Это приложение будет содержать инструкции о том, как определять модули Схемы XML, совместимые с реализациями Модуляризации XHTML, через Схему XML после того, когда XML Schema станет Рекомендациями W3C.
[] [] []

Правила Именования

Типы Документа Основного Языка XHTML обязаны придерживаться соглашений строгого именования, чтобы программы и пользователи могли сразу определять отношение типов документов и XHTML. Имена типов документов, реализуемых как типы документов XML, определяются через Formal Public Identifiers (FPI/Формальные Публичные Идентификаторы). Внутри FPI поля разделяются двойным слэшем (//).

Различные поля обязаны быть скомпонованы следующим образом:

Ведущее поле обязано быть "-" для обозначения приватно определённого ресурса.

Второе поле обязано содержать имя организации, ответственной за поддержку именованного объекта. Для этих имён организаций не существует формальной регистрации. Каждая организация должна определять (иметь) уникальное имя. Например, имя, используемое W3C, это W3C.

Третье поле содержит три конструкции: класс public text, после которого следует описание public text. Первая лексема третьего поля это класс public text, который должен придерживаться ISO 8879 Clause 10.2.2.1 Public Text Class. Только документы, соответствующие Основному Языку XHTML, должны начинать описание public text лексемой XHTML. Описание public text должно содержать строковой XHTML, если тип документа соответствует Integration Set/Интегрированному Набору. Поле обязано также содержать определённый организацией уникальный идентификатор (например, MyML 1.0). Этот идентификатор должен быть образован из уникального имени и идентификатора версии, который может обновляться по мере развития типа документа.

Четвёртое поле определяет язык, на котором объект разработан (например, EN).

При использовании этих правил, имя типа документа, соответствующего Основному Языку XHTML, может быть таким
-//MyCompany//DTD XHTML MyML 1.0//EN.

Имя модуля, соответствующего семейству XHTML, может быть

-//MyCompany//ELEMENTS XHTML MyElements 1.0//EN.

Имя типа документа, соответствующего XHTML Integration Set/Интегрированному Набору, может быть
-//MyCompany//DTD Special Markup with XHTML//EN.

Представление

%xhtml-inlpres.mod;]]>
%xhtml-blkpres.mod;]]>

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

Этот раздел является информативным.
В этом разделе определён образец абстрактного модуля как пример использования преимуществ синтаксических правил, определённых выше.

Поскольку в этом примере сделана попытка использовать все определённые синтаксические элементы, он весьма сложен. Типичные определения модуля намного проще этого.

Наконец, обратите внимание, что этот модуль ссылается на коллекцию атрибутов Common. Это - коллекция, определённая в спецификации Модуляризации XHTML, включающая все базовые атрибуты, необходимые для большинства элементов.

Разработка ОТД (определений типа документа) в определённых и расширенных модулях

Содержание

E.1.

E.2.

E.3.

E.3.1.

E.3.2.

E.4.

E.4.1.

E.4.2.

E.4.3.

E.4.4.

E.5.

Этот раздел является информативным.
Главной целью определения модулей XHTML и общей методологией модуляризации является облегчение разработки типов документов на базе XHTML. Эти типы документов могут расширять XHTML путём интеграции дополнительных возможностей (например, ) или могут определять поднаборы XHTML для использования в специализированных устройствах.

В этом разделе описывается техника, которую дизайнеры типов документов обязаны применять, чтобы использовать преимущества реализации ОТД XML этой архитектуры модуляризации. Это достигается применением техники Модуляризации XHTML прогрессивно усложняющимися способами и созданием в результате сложного документа из различных модулей.
Заметьте, что эти примеры ни в коем случае не требуют модификации самих предоставляемых XHTML модулями файловых объектов. Объекты файла модуля XHTML полностью параметризованы, так что можно, с помощью раздельных определений модулей и файлов драйверов, установить определение и модель содержимого каждого элемента и каждой иерархии элементов.
Вспомним, наконец, что большинство пользователей XHTML не собираются быть авторами ОТД. Авторы ОТД - это, как правило, те, кто определяют специализированную разметку, улучшающую читабельность и упрощающую отображение документа или облегчающую обработку документов машиной, либо это дизайнеры клиентских приложений, которым необходимо определить специализированное ОТД для конкретного приложения.

Рассмотрим эти варианты:
Организация предоставляет подписчикам информацию через интерфейс Web. Эта организация хранит информацию о своих подписчиках в базе данных на основе XML. Один из способов передачи этой информации из БД в Web - внедрить записи XML из БД непосредственно в документ XHTML.

Поскольку можно просто внедрить эти записи, организация могла бы определить модуль ОТД, в котором описаны записи, присоединить этот модуль к ОТД XHTML и затем создать полное ОТД для страниц.

Эта организация может затем иметь доступ к данным в новых элементах через Document Object Model , проверять документы, предоставлять определения стилей для каскадируемых элементов, используя Cascading Style Sheets , и т.д. Затратив определённое время на определение структуры данных и создание ОТД, используя процессы, определённые в этом разделе, организация сможет реализовать все преимущества XML.

Разработчики клиентов Internet создают специализированное устройство. Это устройство будет поддерживать только поднабор XHTML и всегда будет иметь доступ к Internet через прокси-сервер, проверяющий содержимое перед тем, как передать его клиенту (для уменьшения обработки на стороне клиента возможных ошибок).

Чтобы удостовериться, что содержимое верно, разработчики создают ОТД, которое является поднабором XHTML, используя процессы, определённые в этом разделе.

Затем они используют новое ОТД на прокси-сервере и в своих новых устройствах, а также делают ОТД доступным для разработчиков содержимого, так что разработчики могут проверять своё содержимое перед тем, как открыть к нему доступ.

Выполнив несколько простых шагов, разработчики клиентов могут использовать определённую в этом документе архитектуру для значительного уменьшения усилий, необходимых для разработки ОТД и иметь уверенность, что эти клиенты полностью поддерживают подключённый поднабор XHTML.

Разработка Схемы с определёнными и расширенными модулями

Это приложение является нормативным.
Это приложение будет содержать инструкции о том, как определять в целом язык разметки, используя модули XHTML, через Схему XML после того, когда XML Schema станет Рекомендациями W3C.
[] [] []

Реализации модулей XHTML

Этот раздел содержит формальное определение каждого Абстрактного Модуля XHTML как модуля ОТД.

Реализации модулей

Реализация модуля состоит из набора типов элементов, набора объявлений списка атрибутов и набора объявлений моделей содержимого, где любой из этих трёх наборов может быть пустым. Объявление списка атрибутов в модуле может модифицировать тип элемента вне типов элементов, определённых в модуле, а объявление модели содержимого может модифицировать тип элемента вне набора типов элементов модуля.
Одним из механизмов реализации являются ОТД XML. ОТД XML это способ описания структуры класса документов XML, в целом известного как тип документа XML.

ОТД XML описаны в Рекомендациях XML 1.0 .

Другим механизмом реализации является Схема XML .

Реализации Модуля ОТД XHTML

Содержание

F.1.

F.1.1.

F.1.2.

F.1.3.

F.2.

F.2.1.

F.2.2.

F.2.3.

F.2.4.

F.2.5.

F.2.6.

F.3.

F.3.1.

F.3.2.

F.3.3.

F.3.4.

F.3.5.

F.3.6.

F.3.7.

F.3.8.

F.3.9.

F.3.10.

F.3.11.

F.3.12.

F.3.13.

F.3.14.

F.3.15.

F.3.16.

F.3.17.

F.3.18.

F.3.19.

F.3.20.

F.3.21.

F.4.

F.4.1.

F.4.2.

F.4.3.

F.4.4.

F.4.5.

F.4.6.

F.4.7.

F.4.8.

Это приложение является нормативным.
В этом приложении Вы найдёте реализации модулей, определённых в , через ОТД XML. Эти реализации модулей могут использоваться Типами Документов Семейства XHTML.

Реализации Модуля XHTML Schema

Это приложение является нормативным.
Это приложение будет содержать реализации модулей, определённых в , через Схему XML Schema после того, когда XML Schema станет Рекомендациями W3C.
[] [] []

Редактирование

ins.qname; %ins.content; > ]]>
]]>

del.qname; %del.content; > ]]>
]]>

Эти Рекомендации специфицируют абстрактную модуляризацию

Эти Рекомендации специфицируют абстрактную модуляризацию XHTML и реализации абстракции с использованием Определения Типа Документа (ОТД) XML.

Данная модуляризация предоставляет средства для создания поднаборов и расширений XHTML - это необходимо в будущем для расширения XHTML на появляющиеся платформы.

Серверные карты изображений

Скриптинг

script.qname; %script.content; > ]]>
]]>

noscript.qname; %noscript.content; > ]]>
]]>

Смешивание нового модуля с модулями в XHTML

В дополнение к предыдущему примеру: чтобы подключить этот модуль в любом месте, где разрешена группа моделей содержимого %Flow.mix, может потребоваться записать нечто такое:

Поскольку класс моделей содержимого %Misc.extra используется в объекте параметра %Misc.class и этот объект параметра используется повсеместно в модулях XHTML, новый модуль становится доступным в расширенном типе документа XHTML.

Сочетаемость

Требования сочетаемости, перечисленные здесь, дают возможность удостовериться, что каркас модуляризации может выражать верный набор целевых модулей, необходимых для сообщества, обслуживаемого каркасом:

[R2.1] Каркас модуля должен давать возможность конструировать абстрактные модули XHTML 1.0.

[R2.2] Каркас модуля должен давать возможность конструировать абстрактные модули, максимально близкие к HTML 4.

[R2.3] Каркас модуля должен давать возможность конструировать абстрактные модули для других Рекомендаций W3C.

[R2.4] Каркас модуля должен давать возможность конструировать абстрактные модули для других типов документов XML.

[R2.5] Каркас модуля должен давать возможность конструировать абстрактные модули для большого количества профилей платформ.

Модуляризация XHTML

1.1.

1.2.

1.3.

1.3.1.

1.3.2.

1.3.3.

1.3.4.

1.3.5.

3.1.

3.2.

3.3.

3.4.

3.5.

3.6.

3.7.

4.1.

4.2.

4.3.

4.4.

4.4.1.

5.1.

5.2.

5.2.1.

5.2.2.

5.2.3.

5.2.4.

5.3.

5.4.

5.4.1.

5.4.2.

5.4.3.

5.5.

5.5.1.

5.5.2.

5.6.

5.6.1.

5.6.2.

5.7.

5.8.

5.9.

5.10.

5.11.

5.12.

5.13.

5.14.

5.15.

5.16.

5.17.

5.18.

5.19.

5.20.

5.21.

5.22.

D.1.

D.2.

D.2.1.

D.2.2.

D.2.3.

D.2.4.

E.1.

E.2.

E.3.

E.3.1.

E.3.2.

E.4.

E.4.1.

E.4.2.

E.4.3.

E.4.4.

E.5.

F.1.

F.1.1.

F.1.2.

F.1.3.

F.2.

F.2.1.

F.2.2.

F.2.3.

F.2.4.

F.2.5.

F.2.6.

F.3.

F.3.1.

F.3.2.

F.3.3.

F.3.4.

F.3.5.

F.3.6.

F.3.7.

F.3.8.

F.3.9.

F.3.10.

F.3.11.

F.3.12.

F.3.13.

F.3.14.

F.3.15.

F.3.16.

F.3.17.

F.3.18.

F.3.19.

F.3.20.

F.3.21.

F.4.

F.4.1.

F.4.2.

F.4.3.

F.4.4.

F.4.5.

F.4.6.

F.4.7.

F.4.8.

G.1.

G.2.

H.1.

H.1.1.

H.1.2.

H.1.3.

H.1.4.

H.1.5.

Внимание !

Официальная нормативная версия этой спецификации возможна только на английском языке и находится по адресу:

Данный перевод НЕ является официальным документом W3C.

Все Авторские Права Принадлежат W3C.
Данный документ может содержать ошибки перевода и опечатки.

Соглашения по синтаксису

Соответствие Документа Семейства XHTML

Соответствие Интеграционному Набору Типа Документа XHTML

Тип документа обязан быть определён с использованием одного из методов реализации, определённого W3C. В настоящий момент они ограничены ОТД (Определение Типа Документа) XML, но XML Schema также будет вскоре доступна. Остальная часть этого раздела относится к "ОТД", хотя другие реализации также возможны.

ОТД, определяющее тип документа, обязано иметь уникальный идентификатор, как определено в , и НЕ использовать строку "XHTML" в своей первой лексеме публичного текстового описания.

ОТД, определяющее тип документа, обязано включать как минимум модули Hypertext, Text и List, определённые в данной спецификации.

Для каждого определённого W3C включаемого модуля все элементы, атрибуты, типы атрибутов (в том числе и любые необходимые списки перечисляемых значений) и любые необходимые модели минимального содержимого обязаны быть включены (и, возможно, расширены) в модель типа содержимого документа.

Если модели содержимого расширены, все элементы и атрибуты (вместе с их типами или любые необходимые списки перечисляемых значений), необходимые в оригинальной модели содержимого, обязаны остаться необходимыми.

ОТД, определяющее тип документа, может определять дополнительные элементы и атрибуты. Однако это обязано происходить в его собственном пространстве имён XML .

Соответствие Модуля Семейства XHTML

Тип документа обязан быть определён с использованием одного из методов реализации, определённого W3C. В настоящий момент они ограничены ОТД (Определение Типа Документа) XML, но XML Schema также будет вскоре доступна. Остальная часть этого раздела относится к "ОТД", хотя другие реализации также возможны.

ОТД, определяющее тип документа, обязано иметь уникальный идентификатор, как определено в .

Если модуль определён с использованием ОТД XML, то он обязан изолировать имена параметров своих объектов путём использования уникальных префиксов или других подобных методов.

Определение модуля обязано иметь текстовое определение, описывающее синтаксические и семантические требования элементов, атрибутов и/или моделей содержимого, которые он объявляет.

Определение модуля обязано не использовать имена элементов, определённые в других определённых W3C модулях, за исключением случаев, когда модели содержимого и элементов идентичны оригинальным или расширяют их, или повторно используемые имена элементов находятся в их собственном пространстве имён (см. ниже).

Элементы и атрибуты определения модуля обязаны быть частью пространства имён XML .

Если модуль определён не W3C, а другой организацией, его пространство имён обязано НЕ быть тем же пространством имён, в котором определены другие модули W3C.

Соответствие Основного Языка Типа Документа XHTML

Тип документа обязан быть определён с использованием одного из методов реализации, определённого W3C. В настоящий момент они ограничены ОТД (Определение Типа Документа) XML, но XML Schema также будет вскоре доступна. Остальная часть этого раздела относится к "ОТД", хотя другие реализации также возможны.

ОТД, определяющее тип документа, обязано иметь уникальный идентификатор, как определено в , и использовать строку "XHTML" в своей первой лексеме публичного текстового описания.

ОТД, определяющее тип документа, обязано включать как минимум модули Structure, Hypertext, Text и List, определённые в данной спецификации.

Для каждого определённого W3C включаемого модуля все элементы, атрибуты, типы атрибутов (в том числе и любые необходимые списки перечисляемых значений) и любые необходимые модели минимального содержимого обязаны быть включены (и, возможно, расширены) в модель типа содержимого документа.

Если модели содержимого расширены, все элементы и атрибуты (вместе с их типами или любые необходимые списки перечисляемых значений), необходимые (REQUIRED) в оригинальной модели содержимого, обязаны остаться необходимыми.

ОТД, определяющее тип документа, может определять дополнительные элементы и атрибуты. Однако это обязано происходить в его собственном пространстве имён XML .

Соответствие Пользовательского Агента (ПА) Семейства XHTML

Чтобы следовать Рекомендациям XML 1.0 , ПА обязан разбирать и выполнять документ XHTML правильно сформированным. Если ПА объявлен как проверяющий ПА, он обязан также проверять документы относительно их ОТД в соответствии с .

Если ПА объявляет о поддержке возможностей, определённых в данной спецификации или требуемых данной спецификацией через нормативные ссылки, он обязан выполнять это способами, соответствующими определениям возможностей.

Когда ПА обрабатывает документ XHTML как общий (родовой) документ , он должен лишь распознавать атрибуты типа ID (напр., атрибут id
большинства элементов XHTML) как идентификаторы фрагмента.

Если ПА обнаруживает элемент, который он не в состоянии распознать, он обязан продолжить обработку потомков этого элемента. Если содержимым является текст, то текст обязан быть представлен (выведен) пользователю.

Если ПА обнаруживает атрибут, который он не в состоянии распознать, он обязан игнорировать всю спецификацию атрибута (т.е. атрибут и его значение).

Если ПА обнаруживает значение атрибута, которое он не в состоянии распознать, он обязан использовать значение по умолчанию данного атрибута.

Если ПА обнаруживает ссылку-мнемонику (отличную от предопределённых), для которой ПА не производит объявлений (что может случиться, если объявление находится во внешнем поднаборе, который ПА не может прочесть), то ссылка-мнемоника должна быть выведена как символы (начиная с амперсанда и заканчивая точкой с запятой), представляющие мнемонику.

При выводе содержимого, ПАгенты, обнаружившие символы или мнемоники, которые ими не распознаются, но не могут быть представлены, должны отобразить документ так, чтобы пользователю было понятно, что нормальное представление невозможно.

SPACE/пробел ( )

HORIZONTAL TABULATION/горизонтальная табуляция ( )

CARRIAGE RETURN/возврат каретки ( )

LINE FEED/прогон строки ( )

Все пробелы, окружающие блок элементов, должны быть удалены.

Комментарии полностью удаляются и не влияют на обработку пробелов. Одиночный пробельный символ с любой стороны комментария рассматривается как два пробельных символа.

Если атрибут 'xml:space' установлен в 'preserve', пробельные символы обязаны быть сохранены и последующие символы LINE FEED внутри блока обязаны не быть конвертированы.

Если атрибут 'xml:space' установлен в 'preserve', тогда:

Ведущие и ведомые пробелы внутри элемента блока обязаны быть удалены.

Символы LINE FEED обязаны быть конвертированы в один из следующих символов: SPACE, ZERO WIDTH SPACE () или ни в один из символов (т.е. удалены).

Выбор результирующего символа зависит от ПА и обусловлен свойствами письма (языка) символов до и после символа LINE FEED.

Последовательность пробелов без символов LINE FEED обязана быть редуцирована до символа SPACE.

Последовательность пробельных символов с одним или более символом LINE FEED обязана быть редуцирована таким же образом до символа SPACE.

Пробелы в значениях атрибутов обрабатываются в соответствии с .

Примечание (информативное): При определении того, как конвертировать символ LINE FEED, ПА должен рассмотреть следующие случаи, когда вид письма с любой стороны от LINE FEED определяет выбор замены. Символы ОБЩЕГО письма (такие как пунктуация) рассматриваются так же, как и письмо с другой стороны:

Если символы до и после LINE FEED принадлежат письму, в котором символ SPACE используется как разделитель слов, то символ LINE FEED должен быть конвертирован в символ SPACE. Примерами такого письма могут служить латиница, греческое и кириллица.

Если символы до и после LINE FEED принадлежат идеографическому письму или системе письма, в которой нет разделителя слов, то LINE FEED должен быть конвертирован в нулевой (пустой/никакой) символ. Примеры такого письма или системы письма - китайский, японский.

Если символы до и после LINE FEED принадлежат неидеографическому письму, в котором нет разделителя слов, LINE FEED должен быть конвертирован в символ ZERO WIDTH SPACE () или в нулевой (пустой/никакой) символ. Примеры такого письма -тайский, кхмерский.

Если условия с (1) по (3) неприменимы, то символ LINE FEED должен быть конвертирован в символ SPACE.

Техническое сообщение Unicode TR#24 (Script Names) предоставляет назначения имён скриптов всем символам.

Соответствие

Эффективность каркаса будет определяться также тем, несколько легко будет тестировать поведение модулей, разработанных в соответствии с каркасом, и тестировать документы, использующий эти модули для проверки:

[R5.1] Должна иметься возможность легализовать документы, сконструированные с использованием элементов и атрибутов из абстрактных модулей.

[R5.2] Должна иметься возможность явно описывать поведение элементов и атрибутов из абстрактных модулей.

[R5.3] Должна иметься возможность проверять поведение элементов и атрибутов из абстрактных модулей.

[R5.4] Должна иметься возможность проверять гибридные типы документа, такие, как тип документа XHTML.

[R5.5] Модули, определённые в соответствии с методами данного документа, не должны будут дублировать имена элементов или объектов параметров, определённых в модулях XHTML.

[] [] []

Совместимость

Данный документ предназначен для того, чтобы каркас модуляризации, описанный здесь, хорошо работал с XML и другими стандартами, разрабатываемыми Рабочим Группами W3C:

[R4.1] Каркас модуля должен строго соответствовать Рекомендациям XML 1.0.

[R4.2] Каркас модуля должен быть совместимым со спецификацией XML Linking Language (XLink) .

[R4.3] Каркас модуля должен быть совместимым со спецификацией Associating Style Sheets with XML documents .

[R4.4] Каркас модуля должен быть способен воспринимать новые Рекомендации W3C, если это необходимо.

[R4.5] Каркас модуля не должен зависеть от ведущейся работы W3C.

[R4.6] Каркас модуля не должен зависеть от работы, выполняемой вне W3C.

Создание Модулей ОТД

Содержание

D.1.

D.2.

D.2.1.

D.2.2.

D.2.3.

D.2.4.

Этот раздел является нормативным.
Модули XHTML реализуются как фрагменты ОТД (Определения Типа Документа). Когда эти фрагменты ассемблируются особым образом (описано в ), результирующее ОТД является представлением полного типа документа. Это представление может затем быть использовано для проверки объектов типа документа.
Ключом для комбинирования этих фрагментов в понятное ОТД являются правила, используемые для определения фрагментов.

Данный раздел определяет эти правила. Если эти правила соблюдаются, авторы ОТД могут быть уверены, что их модули будут чётко взаимодействовать с другими XHTML-совместимыми модулями.
Модули, соответствующие этим правилам, должны также удовлетворять требованиям соответствия, определённым в , чтобы называться Модулями Семейства XHTML.

Создание нового ОТД

Наконец, некоторые авторы ОТД захотят начать с нуля, используя сценарий Модуляризации XHTML в качестве набора утилит для построения нового языка разметки. Этот язык обязан быть построен с минимальным необходимым количеством модулей из XHTML. Он может также содержать другие определённые в XHTML модули или любые другие модули, которые автор хочет использовать.

В данном примере мы возьмём необходимые модули XHTML, добавим некоторые определённые в XHTML модули и добавим всё это в модуль, определённый нами выше.
Сначала нужно использовать предоставляемый XHTML для нового модуля квалифицированных имён, изменив его так, чтобы определить квалифицированные имена и пространство имён для наших новых элементов:

%MyML-datatypes.mod;

]]>

]]>

]]>

Затем определим модуль, который определяет элементы и атрибуты, используя предоставляемый XHTML :

Теперь построим описание модели содержимого, которое "прицепляет" новые элементы и атрибуты к другим элементам XHTML.

Следующий пример скопирован по образцу модели содержимого XHTML Basic, но является законченным самостоятельным модулем модели содержимого:

Наконец, используем предоставляемый XHTML для нового ОТД, изменённый соответствующим образом для нашего нового языка разметки:

%xhtml-framework.mod;

%xhtml-text.mod;

%xhtml-hypertext.mod;

%xhtml-list.mod;

%MyML-elements.mod;

%xhtml-image.mod;

%xhtml-meta.mod;

%xhtml-struct.mod;

Создание нового ОТД

До сих пор примеры этого раздела описывали методы расширения XHTML и модели содержимого XHTML. Поскольку это уже выполнено, следующим шагом станет объединение модулей, составляющих ОТД, в единый драйвер ОТД, включающий новые определения так, что они соответствующим образом переопределяют и дополняют базовые определения XHTML.

Создание ОТД путём расширения XHTML

Теперь создалась ситуация, когда завершённый дополнительный комплексный модуль добавлен к XHTML (или к поднабору XHTML). В сущности, это тот же самый тривиальный вышеприведённый пример, единственное отличие заключается в том, что добавляемый модуль встроен в ОТД по ссылке, а не включает новые определения непосредственно в ОТД.
Одним из таких сложных модулей является ОТД для . Чтобы объединить MathML и XHTML в единое ОТД, автору понадобится лишь решить, где содержимое MathML должно легализоваться в документе, и добавить корневой элемент MathML в модель содержимого в этой точке.

Во-первых, определим модуль модели содержимого, устанавливающий ОТД MathML и подключающий его к модели содержимого:
%XHTML1-math;

Затем определим драйвер ОТД, идентифицирующий наш новый модуль модели содержимого как модель содержимого для ОТД и передающий процесс драйверу XHTML 1.1 (например):
%xhtml11.dtd;

Создание ОТД путём удаления и замены модулей XHTML

Другой способ использования авторами модулей ОТД XHTML - это определение ОТД, являющегося поднабором семейства типа документа XHTML (поскольку, например, существуют утилиты или программы, поддерживающие только поднабор XHTML). Это будет лишь немного сложнее, чем в предыдущем примере. Базовые шаги таковы:

Взять ОТД семейства XHTML как базу нового типа документа (мы будем использовать XHTML 1.1).

Выбрать модули для удаления из этого ОТД.

Определить новое ОТД, которое "IGNOREs/ИГНОРИРУЕТ" модули.

Ввести некоторые новые модули.

Например, рассмотрим устройство, использующее модули XHTML, но без форм или таблиц. ОТД для такого устройства может выглядеть так:

%xhtml-basic-table.mod; %xhtml11.mod;
Заметьте, что это не изменяет ОТД модели содержимого XHTML 1.1. Однако, поскольку XML игнорирует элементы моделей содержимого, которые не определены, элементы форм и таблиц автоматически удаляются из этой модели.

Создание простого ОТД

Используя простой предыдущий пример, можно определить новое ОТД, которое использует и довольно легко расширяет модули XHTML.

Во-первых, определим в модуле новые элементы и их модель содержимого:

%xhtml-basic-model.mod;
Затем определяем драйвер ОТД для нового языка:

%xhtml-datatypes.mod;

]]>

]]>

%xhtml-basic.dtd;

При использовании этого ОТД имеется возможность включить использование префиксов пространства имён XML. Для этого начало документа, использующего это новое ОТД, может выглядеть так:

]> Пример, использующий значения по умолчанию.

Это содержимое в пространстве имён XHTML.

Это содержимое в пространстве имён SimpleML.

Missing image

Специальные символы XHTML

Ссылки

Содержание

G.1.

G.2.

Это приложение является нормативным.

Статус этого документа

Этот раздел описывает статус документа на момент публикации. Другие документы могут заменять этот документ.

Статус самых последних документов отслеживается наW3C.
Этот документ просмотрен Членами W3C и другими заинтересованными сторонами и утверждён Директором как Рекомендации W3C. Это постоянный документ, и он может использоваться как справочный материал или для цитирования из других документов как нормативный справочник. Роль W3C в составлении Рекомендаций заключается в том, чтобы привлечь внимание к данной спецификации и способствовать её широкому распространению. Это увеличит функциональность и возможности Web.
Этот документ создан как часть и (). Цели и задачи HTML Working Group обсуждаются в . Основной контактёр W3C по работе над HTML - .
Список текущих Рекомендаций W3C и другая техническая документация находятся по адресу

.
Публичная дискуссия о возможностях HTML проходит в списках рассылки

().
Чтобы подписаться, вышлите email на со словом subscribe в строке subject.
Пожалуйста, сообщайте об ошибках, обнаруженных в этом документе, по адресам:

()

и (переводчик русской версии).

Структура

title.qname; %title.content; > ]]>
]]>

head.qname; %head.content; > ]]>

]]>

body.qname; %body.content; > ]]>

]]>

html.qname; %html.content; > ]]>

]]>

Таблица стилей

style.qname; %style.content; > ]]>
]]>

Таблицы

table.qname; %table.content; > ]]>
]]>

caption.qname; %caption.content; > ]]>
]]>

thead.qname; %thead.content; > ]]>

]]>

tfoot.qname; %tfoot.content; > ]]>
]]>

tbody.qname; %tbody.content; > ]]>
]]>

colgroup.qname; %colgroup.content; > ]]>
]]>

col.qname; %col.content; > ]]>
]]>

tr.qname; %tr.content; > ]]>
]]>

th.qname; %th.content; > ]]>
]]>

td.qname; %td.content; > ]]>
]]>

Target/Целевой

Текст

%xhtml-inlstruct.mod;]]>
%xhtml-inlphras.mod;]]>
%xhtml-blkstruct.mod;]]>
%xhtml-blkphras.mod;]]>

Термины и Определения

Этот раздел является информативным.
В то время как многие термины определены в месте использования, следующие определения используются по всей спецификации. Настоятельно советуем хорошо ознакомиться с Рекомендациями W3C XML 1.0 .
abstract module/абстрактный модуль
объединение спецификаций типов документов, относящихся к отдельному типу содержимого, которое (объединение) относится к конструкции разметки, отражающей этот отдельный тип.
content model/модель содержимого
объявленная структура разметки, допустимая в объектах данного типа элемента. XML 1.0 различает два типа: элементы, содержащие только содержимое элемента (не символьные данные), и элементы смешанного содержимого (элементы, которые могут содержать символьные данные, иногда перемежаемые необязательными дочерними элементами). Последние характеризуются спецификацией содержимого, начинающейся строкой "#PCDATA" (обозначающей символьные данные).
document model/модель документа
эффективная структура и ограничения данного типа документа. Модель документа образует абстрактное представление физических или семантических структур класса документов.
document type/тип документа
класс документов, разделяющих общие абстрактные структуры. Определение ISO 8879 таково: "класс документов, имеющих сходные характеристики; например, газета, статья, технический справочник или памятная записка. (4.102)"
document type definition (DTD)/определение типа документа (ОТД)
формальное, читаемое машиной выражение правил структуры и синтаксиса XML, которым объект документа специфического типа документа обязан соответствовать; тип схемы документа в XML 1.0 для легализации соответствия объекта документа его заявленному типу документа. Одна и та же модель разметки может быть выражена различными ОТД.
driver/драйвер
обычно небольшой файл, используемый для объявления и установки модулей ОТД. Хорошим тоном считается, если драйвер ОТД не содержит объявлений разметки, составляющих любую часть модели документа.
element/элемент

объект (данного) типа элемента.

element type/тип элемента

определение элемента, то есть контейнер для отдельного семантического класса содержимого документа.

entity/объект

объект это логическая или физическая единица хранения содержимого документа. Объекты могут состоять из разбираемой разметки XML или символьных данных или неразбираемого (т.е. не-XML, возможно - нетекстового) содержимого. Содержимое объекта может быть определено полностью в объекте документа ("внутренние объекты") или вне объекта документа ("внешние объекты"). В разобранных объектах замещающий текст может содержать ссылки на другие объекты.

entity reference/ссылка на объект

строка-мнемоника, используемая в качестве ссылки на содержимое объявленного объекта (напр., "&" для "&", "<" для "<", "©" для "©".)

generic identifier/общий идентификатор

имя, идентифицирующее тип элемента. Также имя типа элемента.

hybrid document/гибридный документ

документ, использующий более одного пространства имён XML. Гибридные документы могут быть определены как документы, содержащие элементы или атрибуты из типов гибридных документов.

instantiate/установить

заместить ссылку на объект на объект с объявленным содержимым.

markup declaration/объявление разметки

синтаксическая конструкция в ОТД, объявляющая объект или определяющая структуру разметки.

В ОТД XML есть 4 специфических типа: объявление объекта определяет связи между мнемоническим символом и его замещающим содержимым; объявление элемента указывает, какой тип элемента может появляться как потомок элемента (см. также модель содержимого); объявление списка определений атрибута определяет набор атрибутов для данного типа элемента и может также устанавливать ограничения типа и значения по умолчанию; объявление нотации определяет связи между именем нотации и внешним идентификатором, ссылающимся на формат неразобранного объекта.

markup model/модель разметки

словарь разметки (т.е. гамма имён элементов и атрибутов , нотаций и т.д.) и грамматика (т.е. описание использования словаря), как определено в определении типа документа (т.е. схема). Модель разметки это конкретное представление модели документа в синтаксисе разметки, и она может быть определена различными уровнями строгого соответствия. Одна и та же модель документа может быть выражена различными моделями разметки.

module/модуль

абстрактная единица модели документа, выраженная как фрагмент ОТД, используемая для объединения объявлений разметки для увеличения гибкости, изменяемости, возможности повторного использования и разборчивости специфических логических или семантических структур.

modularization/модуляризация

реализация модели модуляризации; процесс составления или деления ОТД путём разделения объявлений разметки на модули или группы для поддержки специфических целей. Модули не могут или могут существовать как отдельные файловые объекты (т.е. физические и логические структуры ОТД могут зеркально отражать друг друга, но такого требования не существует).

modularization model/модель модуляризации

абстрактный дизайн определения типа документа (ОТД) для поддержки целей модуляризации, таких как возможность повторного использования, расширяемость, экспрессивность, лёгкость документирования, уменьшение размера кода, целостность и интуитивность использования.

Важно отметить, что модель модуляризации диаметрально противоположна модели документа, которую описывает, поэтому эти две совершенно различные модели модуляризации могут описывать один и тот же документ.

parameter entity/объект параметра

объект, область использования которого - пролог документа (т.е. внешний поднабор/ОТД или внутренний поднабор). Объекты параметров не допускаются в объекте документа.

parent document type/родительский тип документа

тип родительского документа в гибридном документе является типом документа корневого элемента.

tag/тэг

конструкция разметки, ограничивающая начало и конец (включая общий идентификатор и другие атрибуты) элемента.

[] [] []

Типы атрибутов

В некоторых случаях необходимо определять типы значений атрибутов или точный набор допустимых значений атрибутов. Следующие типы атрибутов (определённые в Рекомендациях XML 1.0) используются в определениях абстрактных модулей:

Тип атрибута
Определение

CDATA	Символьные данные.
ID	Идентификатор, уникальный в пределах документа.
IDREF	Ссылка на идентификатор, уникальный в пределах документа.
IDREFS	Список разделённых пробелами ссылок на идентификаторы, уникальные в пределах документа.
NAME	Имя с теми же ограничениями на вводимые символы, что и предыдущий ID.
NMTOKEN	Имя, составленное исключительно из лексем имён, как определено в XML 1.0 .
NMTOKENS	Одно или более разделённых пробелами значений NMTOKEN.
PCDATA	Обрабатываемые символьные данные.

В дополнение к этим предопределённым типам данных, Модуляризация XHTML определяет следующие типы данных и их семантику:

Тип данных
Описание

Character	Одиночный символ из .
Charset	Набор символов, как в .
Charsets	Список разделённых пробелами наборов символов (кодировок), как в .
Color	Значение атрибута типа "Color" относится к определению цвета, как специфицировано в [SRGB]. Значение цвета может быть 16-ричным числом (с префиксом из знака #) или одним из следующих 16 названий цвета. Названия цвета чувствительны к регистру.

Названия цвета и значения sRGB

	Black = "#000000"		Green = "#008000"
	Silver = "#C0C0C0"		Lime = "#00FF00"
	Gray = "#808080"		Olive = "#808000"
	White = "#FFFFFF"		Yellow = "#FFFF00"
	Maroon = "#800000"		Navy = "#000080"
	Red = "#FF0000"		Blue = "#0000FF"
	Purple = "#800080"		Teal = "#008080"
	Fuchsia = "#FF00FF"		Aqua = "#00FFFF"

Таким образом, значения цвета "#800080" и "Purple" оба относятся к пурпурному цвету.
ContentType

Тип содержимого, как в .
ContentTypes	Список разделённых запятыми типов содержимого, как в .
Coords	Список разделённых запятыми координат, используемых при определении областей.
Datetime	Информация о дате и времени.
FPI	Символьная строка, представляющая SGML Formal Public Identifier (формальный публичный идентификатор).
FrameTarget	Имя фрэйма, используемого в качестве целевого для результата определённых действий.
LanguageCode	Код языка, как в .
Length	Размер. Значение может быть в пикселах или в процентах от доступного вертикального или горизонтального пространства. Таким образом, значение "50%" означает половину доступного пространства.
LinkTypes

Авторы могут использовать следующие распознаваемые типы ссылок, перечисленные здесь с их соответствующими интерпретациями.

Значение LinkTypes ссылается на список разделённых пробелами типов ссылок. Пробелы внутри типов ссылок не допускаются.

Эти типы ссылок чувствительны к регистру, т.е. "Alternate" - это то же самое, что и "alternate".

Пользовательские агенты (ПА), поисковые машины и т.п. могут интерпретировать эти типы ссылок по-разному. Например, ПА могут предоставлять доступ к связанным документам через навигационную панель.

Alternate/Альтернативный

Означает замещающие версии документа, в котором находится ссылка. При использовании вместе с атрибутом hreflang

подразумевает переведённую версию документа. При использовании вместе с атрибутом media подразумевает версию, разработанную для другого носителя.

Stylesheet/Таблица стилей

Ссылается на внешнюю таблицу стилей. См. детали в . Используется вместе с типом ссылки "Alternate" в переключаемых пользователем альтернативных таблицах стилей.

Start/Старт

Ссылается на первый документ в коллекции документов. Этот тип ссылки сообщает поисковым машинам, какой документ рассматривается автором в качестве стартового документа коллекции.

Next/Следующий

Ссылается на следующий документ в линеарной последовательности документов. ПА могут выбрать предзагрузку документа "next", чтобы уменьшить время предполагаемой загрузки.

Prev/Пред(ыдущий) Ссылается на предыдущий документ в упорядоченной серии документов. Некоторые ПА также поддерживают синоним "Previous". Contents/Содержание Ссылается на документ, служащий в качестве оглавления. Некоторые ПА также поддерживают синоним ToC (от "Table of Contents"). Index/Индекс Ссылается на документ - индекс текущего документа. Glossary/Словарь Ссылается на документ - справочник терминов, относящихся к текущему документу. Copyright/Авторские права Ссылается на запись об авторских правах на текущий документ. Chapter/Глава Ссылается на документ, служащий в качестве главы в коллекции документов. Section/Раздел Ссылается на документ, служащий в качестве раздела в коллекции документов. Subsection/Подраздел Ссылается на документ, служащий в качестве подраздела в коллекции документов. Appendix/Приложение Ссылается на документ, служащий в качестве приложения в коллекции документов. Help/Помощь Ссылается на документ, предлагающий помощь (более подробную информацию, ссылки на другие информационные ресурсы и т.д.) Bookmark/Закладка Ссылается на закладку. Закладка это ссылка на определённую точку в расширенном документе. Атрибут title может использоваться, например, для пометки закладки. Заметьте, что в документе может быть определено несколько закладок. MediaDesc Атрибут MediaDesc это список разделённых запятыми медиа-дескрипторов. Ниже дан список распознаваемых медиа-дескрипторов:

screen

Подразумевается нестраничный экран компьютера.

tty

Предназначен для носителей, использующих фиксированную символьную решётку, таких как телетайпы, терминалы или портативные устройства с ограниченными возможностями экрана.

tv

Предназначен для устройств типа телевизора (низкое разрешение, цвет, ограниченные возможности прокрутки изображения).

projection

Предназначен для проекторов.

handheld

Предназначен для миниатюрных ручных устройств (маленький экран, монохромный, растровая графика, ограниченные частотные характеристики).

print

Предназначен для страничных непрозрачных материалов и документов, просматриваемых на экране в режиме предварительного просмотра для печати.

braille

Предназначен для осязательных брайль-устройств.

aural

Предназначен для речевых синтезаторов.

all

Подходит для всех устройств.

В будущих версиях XHTML могут быть введены новые значения и могут быть разрешены параметризованные значения. Для облегчения процесса введения этих расширений соответствующие ПА обязаны быть способны разбирать значения атрибута media следующим образом:

Значением является список разделённых запятыми вхождений. Например,

media="screen, 3d-glasses, print and resolution > 90dpi"

отображается в:

"screen" "3d-glasses" "print and resolution > 90dpi"

Каждое вхождение усекается сразу перед первым символом, не являющимся буквой US ASCII [a-zA-Z] (ISO 10646 hex 41-5a, 61-7a), цифрой [0-9] (hex 30-39) или дефисом-минусом (hex 2d). В примере это даёт:

"screen" "3d-glasses" "print"

Нечувствительный к регистру подбор выполняется затем с набором типов носителя, определённым выше. ПА могут игнорировать несовпадающие вхождения. В примере останутся screen и print.

Примечание. Таблицы стилей могут включать медиа-зависимые вариации (например, конструкция CSS @media). В таких случаях лучше будет использовать "media =all". MultiLength Значением может быть Length или относительный размер. Относительный размер имеет форму "i*", где "i" это целое число. При распределении пространства между элементами, претендующими на это пространство, ПА выделяют сначала пикселные и процентные размеры, затем делят оставшееся свободное пространство между относительными размерами. Каждое относительное значение получает часть доступного пространства пропорционально целому числу, предшествующему "*". Значение "*" эквивалентно "1*". Таким образом, если 60 пикселов пространства доступны после того, как ПА распределил абсолютные и процентные размеры, и соперничающие относительные размеры - 1*, 2* и 3*; то 1* получит 10 пикселов, 2* получит 20 пикселов, а 3* получит 30 пикселов.

MultiLengths	Список разделённых запятыми элементов типа .
Number	Одна или более цифр.
Pixels	Значение - целое число, представляющее количество пикселов канвы (экрана, листа). Таким образом, значение "50" это 50 пикселов. См. нормативную информацию об определении пиксела в .
Script	Данные скрипта могут быть содержимым элемента "script" и значением атрибутов внутренних событий. ПА обязаны не разбирать данные скрипта как разметку HTML, а обязаны, вместо этого, передавать их как данные машине скриптов. Чувствительность к регистру данных скрипта зависит от языка скриптов. Обратите внимание, что данные скрипта, являющиеся содержимым элемента, не могут содержать символьных ссылок, а данные скрипта, являющиеся значением атрибута - могут содержать их.
Shape	Очертания (форма) области.
Text	Произвольные текстовые данные, как правило - на человеческом языке.
URI	Uniform Resource Identifier (Универсальный Идентификатор Ресурса), как в .
URIs	Список разделённых пробелами Uniform Resource Identifiers, как в .

Типы данных XHTML

Типы содержимого

Определения абстрактных модулей определяют минимальные, атомарные модели содержимого для каждого модуля. Эти минимальные модели содержимого ссылаются на элементы в самом модуле.

Они могут также ссылаться на элементы в других модулях, от которых абстрактный модуль зависит.

Наконец, модель содержимого во многих случаях требует, чтобы текст допускался как содержимое для одного или более элементов. В этих случаях символ, используемый в тексте, является PCDATA. Это - термин, определённый в Рекомендациях XML 1.0, который относится к обработке символьных данных. Тип содержимого может также быть определён как EMPTY, что означает: элемент не имеет содержимого в своей модели минимального содержимого.

Требования

Цели дизайна из предыдущего раздела ведут к появлению большого количества требований к каркасу модуляризации. Эти требования, обобщённые в данном разделе, могут в дальнейшем быть классифицированы в соответствии с основными описанными возможностями каркаса.

Внутренние события

Бизнес в интернете: Сайты - Софт - Языки - Дизайн