Создавая XML документ разработчик сам решает: как назвать теги, в каком порядке они будут следовать, какие данные будут записаны в том или ином элементе, будут ли у элемента атрибуты или нет и многое другое. Без формального описания структуры документа этим самым документом может воспользоваться только его разработчик. В случае если разработанный XML документ предназначен для передачи во внешний мир, например партнерам по бизнесу, и если к тому же планируется получать в ответ документы, написанные в том же самом формате без определения типов документов (*.DTD, определения типов документов описывают информационную структуру документа. В DTD перечисляются возможные имена элементов, определяются имеющиеся атрибуты для каждого типа элементов и описывается вложенность элементов.
XML используется в качестве средства для описания грамматики других языков. И таким образом разрабатывая некоторый язык для написания XML документов в той или иной области нам придется разработать словарь данной области деятельности. DTD по определению содержат всю информацию которая может появиться в XML документе. Все, что входит в проект, должно быть включено в DTD. Таким образом DTD описания в сущности и является таким словарем. Современный мир меняется достаточно динамично поэтому заранее не известно какая информация может потребоваться в дальнейшем и для того что бы не пришлось часто изменять структуру документов обычно разрабатываемый словарь включает в себя все что может понадобиться для конкретных видов бизнеса или промышленности. Это позволяет использовать определения DTD как средство анализа и проектирования. Приложения XML взаимодействуют друг с другом на основе словарей, которые они понимают, так что определение DTD помогает понять, что может описать приложение.
Другое применение DTD это проверка написанного XML документа на корректность. Правильно оформленные документы, написанные в соответствии со всеми правилами, описанными в спецификации XML, не могут быть проверены на предмет ошибок. Пропущенные ошибки могут вызвать повреждение программы обрабатывающей данные документы, либо ввод в систему неверных данных. Но если документ ссылается на определение DTD, то, используя проверяющий на допустимость анализатор можно проверить, есть ли в нашем документе ошибки. Анализатор затребует DTD и убедится, что документ соответствует описанным в нем грамматическим правилам. Анализатор обнаруживает структурные ошибки и ошибки содержания, что намного уменьшает объем проверок, выполняемых логикой приложения.
Для связывания декларации DTD с экземпляром документа в версии XML 1.0 предлагается специальная декларация DOCTYPE. Она должна следовать после декларации XML и предшествовать любым элементам документа. Тем не менее, между декларациями XML и DOCTYPE могут находиться комментарии и команды обработки.
Декларация DOCTYPE содержит ключевое слово DOCTYPE, за которым следует имя корневого элемента документа, а затем конструкция с декларациями содержания. Перед разъяснением этого утверждения рассмотрим пример расположения декларации DOCTYPE в экземпляре документа. Ниже приводятся первые три строчки документа XML:
.. <xml version ="1.0" ?> <!DOCTYPE root_element_name … > <root_element_name > …
Можно написать внешнее подмножество деклараций в отдельном файле DTD, включить внутреннее подмножество в тело декларации DOCTYPE или сделать то и другое. В последнем случае (смешение внутренних и внешних DTD ) во внутренних DTD могут быть заданы новые декларации или переписаны те, что содержатся во внешних (по определению спецификации XML анализаторы сначала читают внутреннее подмножество, и потому содержащиеся там декларации пользуются приоритетом).
Декларации XML могут содержать атрибут standalone, принимающий только значения "yes" и "nо". Если значение атрибута равно yes, то внешние для экземпляра документа декларации не влияют на информацию, передаваемую документом использующему его приложению. Значение no показывает, что существуют внешние декларации со значениями, необходимыми для правильного описания содержания документа - например конкретные значения по умолчанию. На практике необязательный атрибут standalone используется редко. Наличие этого атрибута со значением, yes не гарантирует отсутствия внешних зависимостей любого типа. Просто внешние зависимости в этом случае не приведут к ошибке в документе, если не будут включены в обработку. Таким образом, в основном этот атрибут представляет собой знак для анализаторов и других приложений, показывающий, нужно ли им использовать какое-либо внешнее содержание.
Блок внутренней декларации разметки тега DOCTYPE состоит из левой квадратной скобки, списка деклараций и правой квадратной скобки:
<! DOCTYPE root_element_name […здесь находятся декларации внутреннего подмножества ... ]>
Внутренние DTD очень полезны, они всегда содержатся в использующем их документе и поэтому их получение анализатором не представляет проблем. Однако внутренние DTD значительно увеличивают размер документа. На практике внутренние DTD чаще всего применяются одновременно с внешними для добавления новых декларации. Если там объявлен какой-либо объект, продекларированный также и во внешнем определении DTD, приоритетом пользуется внутреннее. Это позволяет осуществлять тонкую настройку деклараций для нужд конкретных документов.
Внешние DTD в некоторых отношениях более гибкие. В данном случае декларация DOCTYPE состоит из обычного ключевого слова и имени корневого элемента, за которым следует еще одно ключевое слово SYSTEM либо PUBLIC, обозначающее источник внешнего определения DTD, а за ним - локализация этого определения. Если ключевое слово SYSTEM, DTD обязано непосредственно и явным образом находится по указанному URL адресу.
Если внешние DTD переписываются очень часто, они начинают терять свое значение, а это признак плохого первоначального проекта.
Ключевое слова PUBLIC предназначено для хорошо известных словарей. Приложение, анализирующее документ из этого словаря, должно использовать некоторую стратегию по поиску соответствующего DTD.
Стандарт XML 1.0 допускает у декларации PUBLIC наличие как публичного URI, так и системного идентификатора. Если работающее с документом приложение или анализатор не могут найти DTD по идентификатору URI с ключевым словом PUBLIC, оно должно использовать системный идентификатор.
Допустимое в документе XML содержание определяется с помощью четырех типов декларации разметки в DTD. В следующей далее таблице показаны связанные с этими декларациями ключевые слова и их значения:
| Конструкция DTD | Значение |
|---|---|
| ELEMENT | Декларация типа элемента XML |
| ATTLIST | Декларация атрибутов, которые могут быть назначены конкретным типам элементов, а также разрешенных значений этих атрибутов |
| ENTITY | Декларация повторно используемого содержания |
| NOTATION | Декларация форматирования для внешнего содержания, которое не должно быть проанализировано (например, двоичные данные), а также для внешних приложений, обрабатывающих содержание |
Первые два типа связаны с информацией, которую мы рассчитываем найти в документе XML, - элементами и атрибутами.
Последние два типа используются для поддержки. Особенно облегчают жизнь разработчика словаря XML сущности. Как правило, они состоят из содержания, которое настолько часто используется в DTD или документе, что оправдывает создание специальной декларации. Применение этой декларации напоминает оператор include в языках C/C++, когда в качестве замены для содержания используется имя.
Нотации описывают содержание, разработанное не на языке XML. Используются они для того, чтобы объявить конкретный класс данных и связать его с внешней программой. Эта внешняя программа становится обработчиком объявленного класса данных. Например, связав с документом изображение в формате JPEG, разработчик желает, чтобы программа приняла и визуализировала двоичные данные в этом формате. Конечно, в таком случае документ зависит от того, какой обработчик имеется в системе, получающей документ. В интересах портативности и переносимости некоторые авторы не приводят ссылки на обработчики. В таком случае нотация превращается просто в механизм набора текста.
Каждый элемент документа XML должен быть описан. Объявление элемента начинается с символов <!ELEMENT, после которых через пробел идет имя элемента и его содержимое. Заканчивается объявление символом "больше". По своему содержанию элементы делятся на четыре группы.
EMPTY.Пример: <!ELEMENT element_name EMPTY>
Пример: <ELEMENT element_name ( elem_1,elem_2)>
#PCDATA, после которого через запятую, как и в предыдущем случае, перечисляются все вложенные элементы (если они имеются).Пример: <ELEMENT element_name (#PCDATA, elem_1,elem_2)> <ELEMENT element_name (#PCDATA)>
ANY.Пример: <ELEMENT element_name ANY>
Иногда из нескольких вложенных элементов или списков (список элементов указанных в скобках) может встретиться только один. В таком случае их имена перечисляются через вертикальную черту( | ). Например:
<!ELEMENT element_name (elem_1,(elem_2|elem_3))> - элемент element_name
должен содержать элемент elem_1,
а затем либо elem_2, либо elem_3.
Элементы появляются именно в таком порядке.
Если вложенный элемент можно записать в объявляемом элементе несколько раз, то необходимо это указать используя звездочку, плюс или вопросительным знак.
? - элемент или список может встретиться нуль или один раз;
* - элемент или список может встретиться нуль или несколько раз;
+ - элемент или список может встретиться один или несколько раз.
Атрибуты элемента объявляются после объявления самого элемента. Все атрибуты одного элемента объявляются сразу, одним списком. Список начинается с символов <!ATTLIST, после них через пробел следует имя элемента, к которому относятся атрибуты. Затем идет имя атрибута, его тип или список значений, которые он может принимать (все значения перечисляются через вертикальную черту, в скобках), признак обязательности присутствия атрибута в элементе или значение по умолчанию (это значение будет использовано, если атрибут не записан явно в XML документе).
Тип атрибута записывается одним из ключевых слов:
CDATA - строка символов.ID - уникальный идентификатор, однозначно определяющий элемент, в котором встретился этот атрибут; значения такого атрибута не должны повторяться в документе. Они играют ту же роль, что и первичные ключи в таблицах баз данных.IDREF - идентификатор, содержащий одно из значений атрибутов типа id, используется в качестве ссылки на другие элементы.IDREFS - идентификатор, содержащий набор значений атрибутов типа id, перечисленных через пробелы; тоже используется в качестве ссылки сразу на несколько элементов.ENTITY - имя непроверяемой анализатором сущности объявленных в этом же описании DTD.ENTITIES - имена непроверяемых сущностей.NMTOKEN - слово, содержащее только символы, применяемые в именах. Атрибуты этого типа могут содержать имена других элементов или атрибутов, например, для того чтобы ссылаться на них.NMTOKENS - слова, перечисленные через пробелы.NOTATION - обозначение расшифрованное в описании DTD.Признак обязательности записывается с использование ключевых слов:
#REQUIRED - атрибут надо обязательно записывать в элементе;#IMPLIED - атрибут необязателен, у него нет значения по умолчанию;#FIXED - у атрибута есть только одно значение, которое записывается тут же, через пробел.Пример: <!ATTLIST city type (город | поселок | деревня) "город"> <!ATTLIST pre xml:lang NMTOKEN "ru_RU"> <!ATTLIST pre xml: space (default | preserve) "preserve">
Ссылки на сущности используются как краткие обозначения для громоздких или часто повторяющихся фрагментов документа XML. Сами сущности подставляемые в документ вместо ссылок, объявляются в описании DTD.
Все сущности можно разделить на три группы:
<!ENTITY, после которых через пробел записывается имя сущности и ее значение в кавычках. Например:<!ENTITY lang "XML">
После такого объявления программа-анализатор, увидев в документе ссылку на сущность lang;, заменить ее на строку XML. Ссылку на сущность можно применять тут же, в описании DTD, уже в следующем объявлении.
SYSTEM или PUBLIC после которого записывается место их расположения. После ключевого слова SYSTEM указывается URI адрес. После слова PUBLIC идет какое-то общеизвестное объявление, после которого через пробел также указывается URI адрес, которым программа-анализатор воспользуется, если не поймет указанного объявления.DTD. Объявление начинается с символов <!ENTITY, после которых через пробел записывается знак процента (%), имя сущности и ее значение в кавычках. Например:<!ENTITY % lang "ru_RU">Ссылка на параметризованную сущность начинается не с амперсанда, а со знака процента, в примере-
%lang;. Введение этой ссылки удобно тем, что при смене языка надо будет поменять значение ru _Ru только в одном месте описания.Объявление инструкций по обработке начинается с символов <!NOTATION, после них записывается имя инструкции, одно из ключевых слов SYSTEM или PUBLIC (причем слова SYSTEM и PUBLIC здесь равнозначны), затем в кавычках - ее расшифровка.
Пример. <!NOTATION image-gif SYSTEM "viewer.ехе">
Это объявление связывает обозначение image-gif с программой обработки изображений, находящейся в файле viewer.exe.
Описание структуры документа XML, выполненное средствами DTD имеет ряд недостатков и ограничений:
DTD отличается от синтаксиса XML. XML документ не может обработать проверяющий на допустимость анализатор XML, но он не обязан предоставлять связанный с этим документом DTD вызвавшему его приложению. К тому же, если мы хотим из приложения обрабатывать определения DTD, нам потребуется отдельный механизм анализа.DTD представляют собой закрытые конструкции. Вся информация должна быть включена только в одно определение DTD. Это не кажется ограничением, пока нет необходимости позаимствовать декларацию или какую-либо иную полезную конструкцию из другого определения DTD.DTD можно логически сконструировать таким образом, чтобы оно включало вложенные определения DTD.DTD практически отсутствует информация о типах данных, точном количестве повторений вложенного элемента и некоторые другие необходимые подробности.Создавая XML документ разработчик сам решает: как назвать теги, в каком порядке они будут следовать, какие данные будут записаны в том или ином элементе, будут ли у элемента атрибуты или нет и многое другое. Без формального описания структуры документа этим самым документом может воспользоваться только его разработчик. В случае если разработанный XML документ предназначен для передачи во внешний мир, например партнерам по бизнесу, и если к тому же планируется получать в ответ документы, написанные в том же самом формате без определения типов документов (*.DTD, определения типов документов описывают информационную структуру документа. В DTD перечисляются возможные имена элементов, определяются имеющиеся атрибуты для каждого типа элементов и описывается вложенность элементов.
XML используется в качестве средства для описания грамматики других языков. И таким образом разрабатывая некоторый язык для написания XML документов в той или иной области нам придется разработать словарь данной области деятельности. DTD по определению содержат всю информацию которая может появиться в XML документе. Все, что входит в проект, должно быть включено в DTD. Таким образом DTD описания в сущности и является таким словарем. Современный мир меняется достаточно динамично поэтому заранее не известно какая информация может потребоваться в дальнейшем и для того что бы не пришлось часто изменять структуру документов обычно разрабатываемый словарь включает в себя все что может понадобиться для конкретных видов бизнеса или промышленности. Это позволяет использовать определения DTD как средство анализа и проектирования. Приложения XML взаимодействуют друг с другом на основе словарей, которые они понимают, так что определение DTD помогает понять, что может описать приложение.
Другое применение DTD это проверка написанного XML документа на корректность. Правильно оформленные документы, написанные в соответствии со всеми правилами, описанными в спецификации XML, не могут быть проверены на предмет ошибок. Пропущенные ошибки могут вызвать повреждение программы обрабатывающей данные документы, либо ввод в систему неверных данных. Но если документ ссылается на определение DTD, то, используя проверяющий на допустимость анализатор можно проверить, есть ли в нашем документе ошибки. Анализатор затребует DTD и убедится, что документ соответствует описанным в нем грамматическим правилам. Анализатор обнаруживает структурные ошибки и ошибки содержания, что намного уменьшает объем проверок, выполняемых логикой приложения.
Для связывания декларации DTD с экземпляром документа в версии XML 1.0 предлагается специальная декларация DOCTYPE. Она должна следовать после декларации XML и предшествовать любым элементам документа. Тем не менее, между декларациями XML и DOCTYPE могут находиться комментарии и команды обработки.
Декларация DOCTYPE содержит ключевое слово DOCTYPE, за которым следует имя корневого элемента документа, а затем конструкция с декларациями содержания. Перед разъяснением этого утверждения рассмотрим пример расположения декларации DOCTYPE в экземпляре документа. Ниже приводятся первые три строчки документа XML:
.. <xml version ="1.0" ?> <!DOCTYPE root_element_name … > <root_element_name > …
Можно написать внешнее подмножество деклараций в отдельном файле DTD, включить внутреннее подмножество в тело декларации DOCTYPE или сделать то и другое. В последнем случае (смешение внутренних и внешних DTD ) во внутренних DTD могут быть заданы новые декларации или переписаны те, что содержатся во внешних (по определению спецификации XML анализаторы сначала читают внутреннее подмножество, и потому содержащиеся там декларации пользуются приоритетом).
Декларации XML могут содержать атрибут standalone, принимающий только значения "yes" и "nо". Если значение атрибута равно yes, то внешние для экземпляра документа декларации не влияют на информацию, передаваемую документом использующему его приложению. Значение no показывает, что существуют внешние декларации со значениями, необходимыми для правильного описания содержания документа - например конкретные значения по умолчанию. На практике необязательный атрибут standalone используется редко. Наличие этого атрибута со значением, yes не гарантирует отсутствия внешних зависимостей любого типа. Просто внешние зависимости в этом случае не приведут к ошибке в документе, если не будут включены в обработку. Таким образом, в основном этот атрибут представляет собой знак для анализаторов и других приложений, показывающий, нужно ли им использовать какое-либо внешнее содержание.
Блок внутренней декларации разметки тега DOCTYPE состоит из левой квадратной скобки, списка деклараций и правой квадратной скобки:
<! DOCTYPE root_element_name […здесь находятся декларации внутреннего подмножества ... ]>
Внутренние DTD очень полезны, они всегда содержатся в использующем их документе и поэтому их получение анализатором не представляет проблем. Однако внутренние DTD значительно увеличивают размер документа. На практике внутренние DTD чаще всего применяются одновременно с внешними для добавления новых декларации. Если там объявлен какой-либо объект, продекларированный также и во внешнем определении DTD, приоритетом пользуется внутреннее. Это позволяет осуществлять тонкую настройку деклараций для нужд конкретных документов.
Внешние DTD в некоторых отношениях более гибкие. В данном случае декларация DOCTYPE состоит из обычного ключевого слова и имени корневого элемента, за которым следует еще одно ключевое слово SYSTEM либо PUBLIC, обозначающее источник внешнего определения DTD, а за ним - локализация этого определения. Если ключевое слово SYSTEM, DTD обязано непосредственно и явным образом находится по указанному URL адресу.
Если внешние DTD переписываются очень часто, они начинают терять свое значение, а это признак плохого первоначального проекта.
Ключевое слова PUBLIC предназначено для хорошо известных словарей. Приложение, анализирующее документ из этого словаря, должно использовать некоторую стратегию по поиску соответствующего DTD.
Стандарт XML 1.0 допускает у декларации PUBLIC наличие как публичного URI, так и системного идентификатора. Если работающее с документом приложение или анализатор не могут найти DTD по идентификатору URI с ключевым словом PUBLIC, оно должно использовать системный идентификатор.
Допустимое в документе XML содержание определяется с помощью четырех типов декларации разметки в DTD. В следующей далее таблице показаны связанные с этими декларациями ключевые слова и их значения:
| Конструкция DTD | Значение |
|---|---|
| ELEMENT | Декларация типа элемента XML |
| ATTLIST | Декларация атрибутов, которые могут быть назначены конкретным типам элементов, а также разрешенных значений этих атрибутов |
| ENTITY | Декларация повторно используемого содержания |
| NOTATION | Декларация форматирования для внешнего содержания, которое не должно быть проанализировано (например, двоичные данные), а также для внешних приложений, обрабатывающих содержание |
Первые два типа связаны с информацией, которую мы рассчитываем найти в документе XML, - элементами и атрибутами.
Последние два типа используются для поддержки. Особенно облегчают жизнь разработчика словаря XML сущности. Как правило, они состоят из содержания, которое настолько часто используется в DTD или документе, что оправдывает создание специальной декларации. Применение этой декларации напоминает оператор include в языках C/C++, когда в качестве замены для содержания используется имя.
Нотации описывают содержание, разработанное не на языке XML. Используются они для того, чтобы объявить конкретный класс данных и связать его с внешней программой. Эта внешняя программа становится обработчиком объявленного класса данных. Например, связав с документом изображение в формате JPEG, разработчик желает, чтобы программа приняла и визуализировала двоичные данные в этом формате. Конечно, в таком случае документ зависит от того, какой обработчик имеется в системе, получающей документ. В интересах портативности и переносимости некоторые авторы не приводят ссылки на обработчики. В таком случае нотация превращается просто в механизм набора текста.
Каждый элемент документа XML должен быть описан. Объявление элемента начинается с символов <!ELEMENT, после которых через пробел идет имя элемента и его содержимое. Заканчивается объявление символом "больше". По своему содержанию элементы делятся на четыре группы.
EMPTY.Пример: <!ELEMENT element_name EMPTY>
Пример: <ELEMENT element_name ( elem_1,elem_2)>
#PCDATA, после которого через запятую, как и в предыдущем случае, перечисляются все вложенные элементы (если они имеются).Пример: <ELEMENT element_name (#PCDATA, elem_1,elem_2)> <ELEMENT element_name (#PCDATA)>
ANY.Пример: <ELEMENT element_name ANY>
Иногда из нескольких вложенных элементов или списков (список элементов указанных в скобках) может встретиться только один. В таком случае их имена перечисляются через вертикальную черту( | ). Например:
<!ELEMENT element_name (elem_1,(elem_2|elem_3))> - элемент element_name
должен содержать элемент elem_1,
а затем либо elem_2, либо elem_3.
Элементы появляются именно в таком порядке.
Если вложенный элемент можно записать в объявляемом элементе несколько раз, то необходимо это указать используя звездочку, плюс или вопросительным знак.
? - элемент или список может встретиться нуль или один раз;
* - элемент или список может встретиться нуль или несколько раз;
+ - элемент или список может встретиться один или несколько раз.
Атрибуты элемента объявляются после объявления самого элемента. Все атрибуты одного элемента объявляются сразу, одним списком. Список начинается с символов <!ATTLIST, после них через пробел следует имя элемента, к которому относятся атрибуты. Затем идет имя атрибута, его тип или список значений, которые он может принимать (все значения перечисляются через вертикальную черту, в скобках), признак обязательности присутствия атрибута в элементе или значение по умолчанию (это значение будет использовано, если атрибут не записан явно в XML документе).
Тип атрибута записывается одним из ключевых слов:
CDATA - строка символов.ID - уникальный идентификатор, однозначно определяющий элемент, в котором встретился этот атрибут; значения такого атрибута не должны повторяться в документе. Они играют ту же роль, что и первичные ключи в таблицах баз данных.IDREF - идентификатор, содержащий одно из значений атрибутов типа id, используется в качестве ссылки на другие элементы.IDREFS - идентификатор, содержащий набор значений атрибутов типа id, перечисленных через пробелы; тоже используется в качестве ссылки сразу на несколько элементов.ENTITY - имя непроверяемой анализатором сущности объявленных в этом же описании DTD.ENTITIES - имена непроверяемых сущностей.NMTOKEN - слово, содержащее только символы, применяемые в именах. Атрибуты этого типа могут содержать имена других элементов или атрибутов, например, для того чтобы ссылаться на них.NMTOKENS - слова, перечисленные через пробелы.NOTATION - обозначение расшифрованное в описании DTD.Признак обязательности записывается с использование ключевых слов:
#REQUIRED - атрибут надо обязательно записывать в элементе;#IMPLIED - атрибут необязателен, у него нет значения по умолчанию;#FIXED - у атрибута есть только одно значение, которое записывается тут же, через пробел.Пример: <!ATTLIST city type (город | поселок | деревня) "город"> <!ATTLIST pre xml:lang NMTOKEN "ru_RU"> <!ATTLIST pre xml: space (default | preserve) "preserve">
Ссылки на сущности используются как краткие обозначения для громоздких или часто повторяющихся фрагментов документа XML. Сами сущности подставляемые в документ вместо ссылок, объявляются в описании DTD.
Все сущности можно разделить на три группы:
<!ENTITY, после которых через пробел записывается имя сущности и ее значение в кавычках. Например:<!ENTITY lang "XML">
После такого объявления программа-анализатор, увидев в документе ссылку на сущность lang;, заменить ее на строку XML. Ссылку на сущность можно применять тут же, в описании DTD, уже в следующем объявлении.
SYSTEM или PUBLIC после которого записывается место их расположения. После ключевого слова SYSTEM указывается URI адрес. После слова PUBLIC идет какое-то общеизвестное объявление, после которого через пробел также указывается URI адрес, которым программа-анализатор воспользуется, если не поймет указанного объявления.DTD. Объявление начинается с символов <!ENTITY, после которых через пробел записывается знак процента (%), имя сущности и ее значение в кавычках. Например:<!ENTITY % lang "ru_RU">Ссылка на параметризованную сущность начинается не с амперсанда, а со знака процента, в примере-
%lang;. Введение этой ссылки удобно тем, что при смене языка надо будет поменять значение ru _Ru только в одном месте описания.Объявление инструкций по обработке начинается с символов <!NOTATION, после них записывается имя инструкции, одно из ключевых слов SYSTEM или PUBLIC (причем слова SYSTEM и PUBLIC здесь равнозначны), затем в кавычках - ее расшифровка.
Пример. <!NOTATION image-gif SYSTEM "viewer.ехе">
Это объявление связывает обозначение image-gif с программой обработки изображений, находящейся в файле viewer.exe.
Описание структуры документа XML, выполненное средствами DTD имеет ряд недостатков и ограничений:
DTD отличается от синтаксиса XML. XML документ не может обработать проверяющий на допустимость анализатор XML, но он не обязан предоставлять связанный с этим документом DTD вызвавшему его приложению. К тому же, если мы хотим из приложения обрабатывать определения DTD, нам потребуется отдельный механизм анализа.DTD представляют собой закрытые конструкции. Вся информация должна быть включена только в одно определение DTD. Это не кажется ограничением, пока нет необходимости позаимствовать декларацию или какую-либо иную полезную конструкцию из другого определения DTD.DTD можно логически сконструировать таким образом, чтобы оно включало вложенные определения DTD.DTD практически отсутствует информация о типах данных, точном количестве повторений вложенного элемента и некоторые другие необходимые подробности.Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.