Ранее мы описали некоторые недостатки определений DTD, они связаны:
Extended Backus Naur Form );W3C выпустил спецификацию, называемую XML Namespaces (пространством имен XML), позволяющую определить контекст элемента в пространстве имен.DTD. Например, такая ситуация возникает при описании большого объема информации, если отдельных DTD недостаточно для охвата всего объема или они трудны для понимания. Возникает она и в системах электронной коммерции при попытках объединить данные вашего делового партнера с вашими. Так же может возникнуть ситуация когда необходимо просто добавить свои настройки к уже существующей DTD для того чтобы обмениваться некоторой информацией в стандартном формате. К сожалению, рекомендация XML не предоставляет способа совмещения нескольким DTD в одном документе без их модификации или создания нового DTD (используя внешние ссылки).В данной главе рассматриваются следующие два понятия - пространство имен и схемы XML. Пространства имен позволяют разработчикам XML разбивать сложную проблему на небольшие фрагменты и объединять несколько словарей в одном документе для полного ее описания. С помощью схем проектировщики словарей создают более точные определения, чем это было возможно в DTD, причем делают это, используя синтаксис XML.
Эти два инструмента помогают решать сложные задачи, возникающие при использовании XML. Пространства имен и схемы позволяют проектировщикам и программистам XML:
DTD ;При проектировании словаря может иметь смысл разбить глобальную проблему на несколько составных частей. Для этого необходимы способы сегментации большой проблемы на несколько словарей. Однако при этом настоящая проблема, которую нужно решить, связана с объединением отдельных DTD в теле одного документа. Данная проблема может возникнуть и в случае если вы, например, работаете на корпорацию в которой скорее всего уже существует набор определений DTD и их использование может существенно облегчит работу, потому что они описывают проблему так, как ее понимают другие. Часто также бывает полезно повторное использование определений DTD, т.е. использование общих конструкций из ранее созданных определений DTD. Если вы разрабатываете приложение, которое должно связываться с программами внешнего партнера, вам, практически, ничего не остается, кроме повторного использования существующих концепций. Имеющиеся определения DTD составляют общепринятый язык, на котором надо говорить, чтобы быть понятым. Если концепция уже существует, надо работать так, чтобы быть понятым в терминах этой концепции.
Когда вы используете полезные для вас определения из DTD других разработчиков или комбинируете сегментированные DTD для создания документа, описывающего сложную проблему, если в ваших документах используются элементы с одинаковыми именами, вы рискуете столкнуться с проблемой неясности и коллизии имен.
Проблема еще больше обостряется при использовании экземпляров имен из нескольких DTD. В этом случае мы не знаем, какой элемент, на какое определение DTD ссылается, такая проблема правильно оформленных документов называется неясностью. Более того, если имена из документа требуют
Пространства имен способны помочь пользователю в двух очень важных случаях. С их помощью можно:
DTD ) или другому описанию элементов и атрибутов.Пространство имен представляет собой совокупность некоторых величин или характеристик, которые могут быть использованы в XML-документах как имена элементов или атрибутов. Пространства имен в XML определяются унифицированным идентификатором ресурса URI (в качестве URI можно использовать адрес DTD на вашем сервере). Он позволяет каждому пространству имен быть уникальным.
Итак, для того чтобы эффективно использовать пространства имен в документе, комбинирующем элементы из различных источников, нам надо определить:
catalog, то, элемент будет называться <catalog:Book> ).Поскольку в разных языках разметок - реализациях XML - могут встретится одни и те же имена тегов и их атрибутов, имеющие совершенно разный смысл, надо иметь возможность их как-то различать. Для этого имена тегов и атрибутов снабжают кратким префиксом, который отделяется от имени двоеточием. Префикс имени связывается с идентификатором, определяющим пространство имен ( namespace ). Все имена тегов и атрибутов, префиксы которых связаны с одним и тем же идентификатором, образуют одно пространство имен, в котором имена должны быть уникальны.
Поскольку необходимо, чтобы, встретив декларацию пространства имен каждый мог распознать ее, для него зарезервируем специальное слово. В соответствии с рекомендацией пространств имен, это слово xmlns. Значением атрибута является идентификатор URI, определяющий используемое пространство имен. Часто это адрес URL определения DTD, но так должно быть не всегда. Префикс и идентификатор пространства имен определяются атрибутом xmlns следующим образом:
<ntb:notebook xmlns:ntb = "http://some.firm.com/2003/ntbml">
Как видите, префикс ntb только что определен, но его уже можно использовать в имени ntb:
<ntb:city ntb:type="поселок">Горелово</ntb:city>
Кроме того, в одном теге могут встречаться сразу несколько пространств имен. Ниже приводится пример смешения нескольких пространств имен:
<catalog:book order:ISBN = "1-861003-11-0">
Элемент book взят из пространства имен catalog, а атрибут ISBN - из order.
Имя вместе с префиксом, например
ntb:notebook
или
ntb:city
называется расширенным, уточненным или квалифицированным именем ( OName. Qualified Name ). Часть имени, записанная после двоеточия, называется локальной частью ( local part ) имени.
Номенклатура названий Web-ресурсов может запутать. Универсальный указатель ресурса ( Uniform Resource Identifier, URI ) представляет собой уникальное имя некоторого ресурса. Смотрите на URI просто как на уникальную строку символов, идентифицирующую пространство имен.
По правилам SGML и XML, двоеточие может применяться в именах как обычный символ, поэтому имя с префиксом - это просто фокус, всякая программа, "не знающая" пространства имен, анализируя документ, рассматривает уточненное имя как обычное имя. Отсюда следует, в частности, что в
Атрибут xmlns может появиться в любом элементе XML, а не только в корневом. Определенный им префикс можно применять в том элементе, в котором записан атрибут xmlns, и во всех вложенных в него элементах. Более того, в одном элементе можно определить несколько пространств имен.
Во вложенных элементах пространство имен можно переопределить, связав префикс с другим идентификатором.
Появление имени тега без префикса в документе, использующем пространство имен, означает, что имя принадлежит пространству имен по умолчанию ( default namespace ).
Хорошо оформленный документ должен использовать пространства имен для всех своих элементов.
Префиксы, начинающиеся с символов xml с любым регистром букв, зарезервированы за самим языком XML. Префикс xmlns используется для связи другого, определяемого, префикса с идентификатором его пространства имен. Префикс xmlns не нужно определять, он введен рекомендацией "Namespaces in XML" и связан там с идентификатором пространства имен http://www.w3.ori/2000 /xmlns/.
Еще один префикс, xml, связан в той же рекомендации с идентификатором http://www.w3.org/XML/1998/namespace. Его тоже не надо определять в документе XML. Никакой другой префикс не может быть связан с этими идентификаторами.
Пока есть только два атрибута с префиксом xml. Для каждого элемента верного документа, в котором используются эти атрибуты, они должны быть объявлены в описании DTD (
Атрибут xml:lang определяет язык, используемый в содержимом элемента. Например, xml:lang="us", xml:lang="en-US", xml:lang="ru-RU". Атрибут можно использовать так:
<р xml:lang="ru_RU" >3апись на русском языке</р>
Атрибут xml:space указывает программе-обработчику, как следует обрабатывать пробельные символы (пробелы, знаки горизонтальной табуляции и символы перевода строки), записанные в содержимом элемента. У атрибута есть всего два значения. Значение default оставляет пробельные символы на усмотрение программы-обработчика.
У деклараций пространств имен имеется область действия, так же, как у деклараций переменных в языках программирования. Это важно, так как пространства имен не всегда декларируются в начале документа XML, иногда это делается в последующих его разделах. Декларация пространства имен применима к элементу, в котором она появляется, а также к потомкам этого элемента, даже если она не определена там явным образом. Имя может ссылаться на пространство имен, только если используется в области действия его декларации.
Однако нам потребуется также смешивать области действия пространств имен в элементах, которые в противном случае наследовали бы другие пространства имен. В связи с этим определены два способа декларации области действия- default (по умолчанию) и qualified (квалифицированный).
Как и следовало ожидать, необходимость добавления префикса к каждому имени в документе быстро становится утомительной. Фактически, введя концепцию области действия имени, мы можем смешивать в нашем документе большое количество префиксов. Если мы определяем пространство имен по умолчанию, то предполагается, что ему принадлежат все неквалифицированные имена внутри области действия его декларации. Таким образом, пространство имен, объявленное по умолчанию в корневом элементе, считается пространством по умолчанию для всего документа и может быть перекрыто только более специфическим пространством имен, объявленным внутри документа.
Чтобы пространство имен сделать пространством имен по умолчанию для некоторой области, достаточно опустить декларацию префикса.
Если префикс объявлен, а затем использован совместно с именем, то говорят что пространство имен явным образом установлено. Чтобы отнести к пространству имен неквалифицированное имя, необходимо объявить пространство по умолчанию, которое включает это неквалифицированное имя (без префикса).
Описанный выше метод работает хорошо, если вы можете четко разделить ваши пространства имен. Но иногда бывает необходимо включить в документ отдельные имена из внешних пространств имен. Вместо того чтобы декларировать пространства имен для целой области, можно использовать квалифицированные имена. Объявите нужные вам пространства имен в начале документа, а затем квалифицируйте их в месте использования.
DTD фактически представляют собой разновидность схемы. Однако, говоря о схемах, разработчики XML, как правило, имеют в виду замену DTD, написанную в соответствии с синтаксисом XML. В принципе, схемы можно считать механизмом создания ограничений, так как, хотя в них объявляются допустимые элементы или атрибуты, мы ограничиваем для пользователя выбор тегов и модели содержания.
Обычно схемы можно считать метаданными, или данными о данных, при разработке схем учитываются не только определения словаря, но и разъяснения связей между определенными типами данных.
Чтобы заменить определения DTD, надо предоставить, по крайней мере, те же возможности, которые предоставляют эти определения. Необходимо определять природу и структуру документов XML. Как и DTD, схемы представляют собой описание компонентов и правил словаря XML. Однако схемы уточняют DTD, позволяя точнее выражать некоторые концепции словаря. Кроме того, в схемах сделано несколько радикальных изменений. Используемый в них синтаксис полностью отличается от DTD. Они позволяют использовать имена из других схем, что решает проблему
Язык XML хорошо согласуется с определениями DTD. В то же время их активно пытаются усовершенствовать. Было выдвинуто множество предложений (некоторые из них доступны на сайте W3C как примечания), они, как это ни парадоксально, не помогают, а затрудняют принятие рекомендации, которая отражала бы наиболее распространенные особенности, требуемые от схем. В частности, многие разработчики настаивают на поддержке
У определений DTD имеется ряд недостатков, которые выявляются при углубленной работе с XML:
Синтаксис определений DTD отличается от языка XML. Он является расширенной Extended Backus Naur Form, ), и многие находят его трудным для чтения и использования. Предлагаемые схемы XML фактически, используют язык XML для описания определяемых ими языков, что устраняет необходимость изучения языка
Использование языка DTD. Разумеется, для DTD существуют специальные анализаторы. Он должен загрузить и прочитать DTD, после чего сможет проверить соответствующий документ на допустимость. К сожалению, не предусмотрена возможность обратиться к DTD из программы, использующей модель DOM. Объектная модель не позволяет получить доступ к метаданным словаря, написанным на языке DTD и сохранит его информацию для себя. Безусловно, было бы удобно, если бы DTD было написано на языке XML, так что мы могли бы исследовать их так же легко, как мы исследуем документы, написанные в соответствии с содержащимися в них правилами. Такая возможность позволила бы при помощи DOM изучить структуру обнаруженных нами словарей и даже модифицировать их правила
Определения DTD представляют собой фиксированную сущность. В них должны существовать все правила словаря. Все, что вам может понадобиться, вы размещаете в вашем словаре. Не создавая внешних объектов, вы не сможете использовать имена из других источников.
Создание и обслуживание ваших собственных подмножеств деклараций разметки станет значительно более удобным в результате использования ссылки на существующее определение. Вы не можете позволить авторам документа включать в него что-нибудь интересное впоследствии, если соответствующее определение отсутствует в DTD. Конечно, не всегда надо предоставлять авторам документов такую свободу, но было бы хорошо использовать части существующей схемы при проектировании нового словаря.
Поскольку все правила словаря должны находиться в DTD, вы не можете смешивать пространства имен. Хотя при помощи пространства имен можно ввести в документ тип элемента, нельзя ссылаться на декларацию элемента в DTD. При его использовании все его элементы должны быть объявлены в DTD.
Одним из существенных преимуществ языка XML является то, что все документы полностью пишутся при помощи общего типа данных - текста. Задачи программирования, однако, требуют использовать и другие типы. Определения DTD предлагают не много других типов данных, что является серьезным недостатком, когда XML применяют в приложениях определенного типа
Итак, определения DTD прекрасно позволяют определять структуры документов. Если учесть, что язык XML произошел от SGML, который также использует DTD, можно легко понять выбор этих определений в спецификации XML 1.0. Однако при использовании XML не только для разметки текста, но и в ситуациях, требующих программирования, описанные ранее ограничения становятся чрезвычайно важными.
В связи с необходимостью создания языка схем, призванного заменить и расширить DTD, было выдвинуто множество предложений. В их число входят:
RDFXML-DataDocument Content Description (DCD )Schema for Object-Oriented XML (SOX)Document Definition Markup Language ( DDML, ранее известный как XSchema )Ни один из этих проектов не был формально поддержан консорциумом W3C, тем не менее, каждый из них рассматривается консорциумом в процессе его работы над схемами XML.
Формат описания ресурсов (
Базовая модель RDF охватывает модель описательных данных, которую можно выразить на языке XML, а также и другие виды синтаксиса. Разработанные при помощи RDF схемы могут определять не только домена и структуры, но также делать выводы об отношениях между обсуждаемыми объектами. RDF - сложный язык, но он обладает большими выразительными возможностями, и поэтому его сложность оправдана.
RDF "стоит на трех китах": это ресурсы, свойства и утверждения.
Ресурсом может быть любая ощутимая сущность в концептуальном домене, на которую можно сослаться по идентификатору URI, в любом объеме - от целого сайта до одного элемента на странице HTML или XML. Это может быть даже объект, недоступный в сети Web, например, напечатанная книга.
Ресурсы типизированы; для определения категорий, из которых берутся специфические экземпляры ресурсов, используется система классов. Поддерживается наследование классов, так что разработчик может определить уровень описания от общего до узко специфического.
Говорят, что ресурсы имеют свойства, которые определяют и описывают их. На свойства налагаются ограничения, которые определяют их форму. Эти ограничения уточняют типы значений, которые могут быть присвоены свойству, и диапазон буквенных значений данного типа, которые могут быть выбраны.
Описав имена и структуры при помощи ресурсов и свойств, можно сформировать утверждения о концептуальном домене. Для этого составляются триплеты из ресурсов (подлежащих), свойств (сказуемых) и значений (дополнений). В специфических утверждениях значения могут быть литералами, а для мощных утверждений, охватывающих целые классы, они представляют собой ресурсы.
Может показаться, что для выполнения простого действия приходится затратить много усилий, но благодаря синтаксису можно делать утверждения о классах. Сделав в схеме больше утверждений, вы явным образом определите больший объем знаний о домене проблемы.
RDF - чрезвычайно мощный язык, допускающий использование выразительных и гибких утверждений. Он решает проблему недостаточной поддержки DTD, сильная типизация является центральной особенностью схемы RDF. Проектирование такой схемы, будучи трудоемким процессом, предполагает декларацию большого количества классов и свойств. Хотя возможность делать значимые утверждения была высоко оценена, она, вероятно, еще более мощная, чем это нужно для описания словарей XML.
Сказанное не означает, что эта возможность не требуется и в других ситуациях. Утверждения RDF позволяют формально описать факты в формате, поддающемся чтению компьютером. Как правило, разрабатываемые нами, словари XML неявным образом полагаются на общее понимание образующих их концепций окружающего нас реального мира. С помощью утверждений RDF мы, по крайней мере, теоретически, можем ввести достаточно информации, чтобы приложение само могло обнаружить дополнительные сведения о словаре. Это позволяет более эффективно использовать новый словарь и определять, в каких случаях он может быть применен к решаемой нами проблеме.
Однако для проектировщика, решающего задачи определения имен, структуры и связей, это может оказаться слишком большой нагрузкой.
Область применения стандарта XML-Data является более умеренной по сравнению с RDF.
Стандарт XML-Data различает синтаксические и концептуальные схемы. Хотя в обеих используется один и тот же язык, они освещают размечаемые нами данные с разных сторон.
Синтаксические схемы - это набор правил, предоставляющих процесс описания документов с помощью разметки; определения DTD являются примером таких синтаксических схем. Синтаксические схемы XML-Data налагают сходные с DTD ограничения на структуру словаря.
Концептуальные модели описывают связи между понятиями или объектами и, как таковые, они идеальны для моделирования реляционных баз данных. При помощи схем XML-Data можно установить связи, основанные на том, что книги содержат заголовки и цены. Это делается способом, отличающимся от синтаксиса любого документа XML. Новый стандарт предназначается для того, чтобы расширить область применения языка XML, включив в него информацию о реляционных базах данных. Главные связи, выраженные ключами в реляционных базах данных, можно формально выразить также и в схемах XML-Data.
XML Data содержит интересные возможности, делающие его более мощным чем DTD:
В языке XML-Data для конструирования схем используется словарь XML, что дает пользователям возможность читать и записывать схемы, не осваивая предварительно новый синтаксис. Это также дает возможность изучать схему или динамически создавать новую при помощи модели DOM и существующих анализаторов.
Язык XML-Data поддерживает DTD. Это могут быть базовые типы, определенные в пространстве имен типов данных, или комплексные пользовательские типы, содержащиеся в схеме, предоставляемой проектировщиком. Приложение больше не должно понимать тип данных элемента или атрибута и перед использованием данных преобразовывать строки или текст в соответствующий формат. Требуемую информацию можно явным образом определить в схеме, а анализаторы выполнят преобразование по желанию приложения.
Язык XML-Data позволяет налагать ограничения на диапазон значений, принимаемых элементами и атрибутами, такие как минимальное и максимальное значения. Эта возможность часто бывает, полезна при проверке допустимости документов XML.
Механизмом, позволяющим повторно использовать элементы, является поддерживаемое языком XML Data наследование типов. Он позволяет выявлять и расширять элементы при описании объектов проблемы, решить которую мы пытаемся с помощью XML. Мы можем написать, например, некоторые общие надтипы, а затем уточнять их в более специфические классы элементов, добавляя или заменяя новые члены в декларации надтипа. В определениях DTD таким же способом используются сущности ( entities ), но наследование типов формализует процесс. Не имея формальной семантики, сущности могут быть использованы неверно, настолько, что это затруднит, а не облегчит работу пользователя. Формальный механизм наследования дает возможность повторного использования, сохраняя при этом некоторый контроль над реализацией этой возможности.
Еще одной мощной возможностью языка XML-Data являются так называемые открытые и закрытые модели содержания. Классическое определение DTD представляет собой закрытую модель. Соответствующие ей документы должны придерживаться правил и не могут содержать ничего, что не соответствует правилам, поскольку все они должны быть описаны в DTD.
Если схема открыта, то соответствующие ей документы могут содержать и другую информацию, не объявленную в DTD. Соответствующая схеме часть документа должна подчиняться заложенным в ней правилам, но мы можем включать в него и другие пункты без ограничений со стороны текущей схемы. Эти пункты могут быть описаны в другой схеме, а могут быть, вообще, никак не ограничены. Можно использовать специальные значения. С точки зрения нашей дискуссии, более важно то, что документы открытой модели представляют собой способ, позволяющий смешивать пространства имен. Фрагмент информации, соответствующий одной схеме, можно включить в середину документа, соответствующего другой. Более того, можно явным образом объявить, что для конкретных элементов используется открытая или закрытая модель содержания. Для этого существует атрибут content, значением которого по умолчанию является open.
ID и IDREFВ языке XML-Data конструкции ID и IDREF расширяются отношениями. В отношении один элемент используется в качестве ключа или индекса для содержания другого элемента. Это непосредственно применимо к моделированию первичных и внешних ключей в реляционных базах.
Предложение Document Content Description ( XML-Data. Это предложение представляет собой словарь RDF, явным образом предназначенный для декларации словарей XML. Его разработчики использовали выразительную мощь одного из стандартов представления метаданных - RDF - для создания стандарта с более ограниченной областью применения. Приблизительно это напоминает то, что язык XML является упрощенным множеством SGML.
Язык XML-Data, хотя в нем и отсутствуют некоторые углубленные возможности последнего. Он строго ориентирован на определение словарей XML. Однако в этом языке сохраняется характерная для XML-Data поддержка XML-Data, XML-Data, XML-Data, позволяет налагать ограничения на значение содержания элементов.
Основанный на языке RDF, DTD. Можно сказать, что в нем широкая мощность языка обменивается на направленную простоту. DTD и отказывается от их углубленной проработки, чтобы получить легко реализуемый стандарт схем XML.
Все, что можно было описать с помощью DTD, содержится в части стандарта XML Schema, посвященного структурам. Поскольку схемы пишутся в соответствии с синтаксисом XML, структуры ссылаются на конструкции на этом языке, при помощи которых можно определять разметку. Это означает, что структуры представляют собой еще одно приложение XML (словарь XML для описания классов документа XML) и как таковое могут использовать схемы для описания самих себя.
Итак, раздел схем спецификации представляет собой ту ее часть, в которой определены элементы и атрибуты для описания схем. Что более важно, в этой части описана модель содержания для элементов. Такая модель явным образом определяет допустимую внутреннюю структуру элементов. Структуры являются сердцем схем XML.
В окружающем нас мире широко используются концепции чисел, строк и множеств, так что написанные на современных языках программы поддерживают большое количество тщательно проработанных систем встроенных типов данных и процедуры по определению новых типов. Добавление типов данных в проект XML Schemas станет важным подспорьем для программистов, использующих XML при работе с данными в своих приложениях. Такая поддержка типов данных предусматривает возможность проверять допустимость значения в документе, а также осуществлять преобразование из текстовой формы во встроенный тип при обработке документа XML. Таким образом, чтобы использовать документы XML в качестве основы для интеграции программ и систем, необходимо иметь возможность перехватывать (определять) типы данных размечаемой нами информации.
Это обеспечивает вторая часть спецификации XML Schemas, носящая название XML Schemas: Datatypes. Она позволяет не только перехватывать базовые типы данных, но и записывать ограничения, налагаемые на данные в домене нашей проблемы. Она позволяет записывать числовые границы, множества и упорядоченные списки, а также создавать маски для допустимых строковых представлений наших данных.
Типы данных схем имеют набор четких значений, называемый пространством значений ( value space ). Он представляет собой абстрактную коллекцию значений, которые может принимать тип. Например, множество целых чисел является пространством значений для типа integer. Это пространство характеризуется ограничивающими свойствами и операциями над значениями в нем.
Часть XML Schema: Datatypes целиком посвящена вопросам определения пространств значений, а затем перечислению ограничивающих свойств типа. Он содержит множество примитивных типов данных и предоставляет механизм генерации новых типов на их основе. В проект входит большое количество таких генерированных типов, находящих широкое применение, но его составители приветствуют создание собственных типов, предназначенных для использования в конкретном приложении.
Ранее мы описали некоторые недостатки определений DTD, они связаны:
Extended Backus Naur Form );W3C выпустил спецификацию, называемую XML Namespaces (пространством имен XML), позволяющую определить контекст элемента в пространстве имен.DTD. Например, такая ситуация возникает при описании большого объема информации, если отдельных DTD недостаточно для охвата всего объема или они трудны для понимания. Возникает она и в системах электронной коммерции при попытках объединить данные вашего делового партнера с вашими. Так же может возникнуть ситуация когда необходимо просто добавить свои настройки к уже существующей DTD для того чтобы обмениваться некоторой информацией в стандартном формате. К сожалению, рекомендация XML не предоставляет способа совмещения нескольким DTD в одном документе без их модификации или создания нового DTD (используя внешние ссылки).В данной главе рассматриваются следующие два понятия - пространство имен и схемы XML. Пространства имен позволяют разработчикам XML разбивать сложную проблему на небольшие фрагменты и объединять несколько словарей в одном документе для полного ее описания. С помощью схем проектировщики словарей создают более точные определения, чем это было возможно в DTD, причем делают это, используя синтаксис XML.
Эти два инструмента помогают решать сложные задачи, возникающие при использовании XML. Пространства имен и схемы позволяют проектировщикам и программистам XML:
DTD ;При проектировании словаря может иметь смысл разбить глобальную проблему на несколько составных частей. Для этого необходимы способы сегментации большой проблемы на несколько словарей. Однако при этом настоящая проблема, которую нужно решить, связана с объединением отдельных DTD в теле одного документа. Данная проблема может возникнуть и в случае если вы, например, работаете на корпорацию в которой скорее всего уже существует набор определений DTD и их использование может существенно облегчит работу, потому что они описывают проблему так, как ее понимают другие. Часто также бывает полезно повторное использование определений DTD, т.е. использование общих конструкций из ранее созданных определений DTD. Если вы разрабатываете приложение, которое должно связываться с программами внешнего партнера, вам, практически, ничего не остается, кроме повторного использования существующих концепций. Имеющиеся определения DTD составляют общепринятый язык, на котором надо говорить, чтобы быть понятым. Если концепция уже существует, надо работать так, чтобы быть понятым в терминах этой концепции.
Когда вы используете полезные для вас определения из DTD других разработчиков или комбинируете сегментированные DTD для создания документа, описывающего сложную проблему, если в ваших документах используются элементы с одинаковыми именами, вы рискуете столкнуться с проблемой неясности и коллизии имен.
Проблема еще больше обостряется при использовании экземпляров имен из нескольких DTD. В этом случае мы не знаем, какой элемент, на какое определение DTD ссылается, такая проблема правильно оформленных документов называется неясностью. Более того, если имена из документа требуют
Пространства имен способны помочь пользователю в двух очень важных случаях. С их помощью можно:
DTD ) или другому описанию элементов и атрибутов.Пространство имен представляет собой совокупность некоторых величин или характеристик, которые могут быть использованы в XML-документах как имена элементов или атрибутов. Пространства имен в XML определяются унифицированным идентификатором ресурса URI (в качестве URI можно использовать адрес DTD на вашем сервере). Он позволяет каждому пространству имен быть уникальным.
Итак, для того чтобы эффективно использовать пространства имен в документе, комбинирующем элементы из различных источников, нам надо определить:
catalog, то, элемент будет называться <catalog:Book> ).Поскольку в разных языках разметок - реализациях XML - могут встретится одни и те же имена тегов и их атрибутов, имеющие совершенно разный смысл, надо иметь возможность их как-то различать. Для этого имена тегов и атрибутов снабжают кратким префиксом, который отделяется от имени двоеточием. Префикс имени связывается с идентификатором, определяющим пространство имен ( namespace ). Все имена тегов и атрибутов, префиксы которых связаны с одним и тем же идентификатором, образуют одно пространство имен, в котором имена должны быть уникальны.
Поскольку необходимо, чтобы, встретив декларацию пространства имен каждый мог распознать ее, для него зарезервируем специальное слово. В соответствии с рекомендацией пространств имен, это слово xmlns. Значением атрибута является идентификатор URI, определяющий используемое пространство имен. Часто это адрес URL определения DTD, но так должно быть не всегда. Префикс и идентификатор пространства имен определяются атрибутом xmlns следующим образом:
<ntb:notebook xmlns:ntb = "http://some.firm.com/2003/ntbml">
Как видите, префикс ntb только что определен, но его уже можно использовать в имени ntb:
<ntb:city ntb:type="поселок">Горелово</ntb:city>
Кроме того, в одном теге могут встречаться сразу несколько пространств имен. Ниже приводится пример смешения нескольких пространств имен:
<catalog:book order:ISBN = "1-861003-11-0">
Элемент book взят из пространства имен catalog, а атрибут ISBN - из order.
Имя вместе с префиксом, например
ntb:notebook
или
ntb:city
называется расширенным, уточненным или квалифицированным именем ( OName. Qualified Name ). Часть имени, записанная после двоеточия, называется локальной частью ( local part ) имени.
Номенклатура названий Web-ресурсов может запутать. Универсальный указатель ресурса ( Uniform Resource Identifier, URI ) представляет собой уникальное имя некоторого ресурса. Смотрите на URI просто как на уникальную строку символов, идентифицирующую пространство имен.
По правилам SGML и XML, двоеточие может применяться в именах как обычный символ, поэтому имя с префиксом - это просто фокус, всякая программа, "не знающая" пространства имен, анализируя документ, рассматривает уточненное имя как обычное имя. Отсюда следует, в частности, что в
Атрибут xmlns может появиться в любом элементе XML, а не только в корневом. Определенный им префикс можно применять в том элементе, в котором записан атрибут xmlns, и во всех вложенных в него элементах. Более того, в одном элементе можно определить несколько пространств имен.
Во вложенных элементах пространство имен можно переопределить, связав префикс с другим идентификатором.
Появление имени тега без префикса в документе, использующем пространство имен, означает, что имя принадлежит пространству имен по умолчанию ( default namespace ).
Хорошо оформленный документ должен использовать пространства имен для всех своих элементов.
Префиксы, начинающиеся с символов xml с любым регистром букв, зарезервированы за самим языком XML. Префикс xmlns используется для связи другого, определяемого, префикса с идентификатором его пространства имен. Префикс xmlns не нужно определять, он введен рекомендацией "Namespaces in XML" и связан там с идентификатором пространства имен http://www.w3.ori/2000 /xmlns/.
Еще один префикс, xml, связан в той же рекомендации с идентификатором http://www.w3.org/XML/1998/namespace. Его тоже не надо определять в документе XML. Никакой другой префикс не может быть связан с этими идентификаторами.
Пока есть только два атрибута с префиксом xml. Для каждого элемента верного документа, в котором используются эти атрибуты, они должны быть объявлены в описании DTD (
Атрибут xml:lang определяет язык, используемый в содержимом элемента. Например, xml:lang="us", xml:lang="en-US", xml:lang="ru-RU". Атрибут можно использовать так:
<р xml:lang="ru_RU" >3апись на русском языке</р>
Атрибут xml:space указывает программе-обработчику, как следует обрабатывать пробельные символы (пробелы, знаки горизонтальной табуляции и символы перевода строки), записанные в содержимом элемента. У атрибута есть всего два значения. Значение default оставляет пробельные символы на усмотрение программы-обработчика.
У деклараций пространств имен имеется область действия, так же, как у деклараций переменных в языках программирования. Это важно, так как пространства имен не всегда декларируются в начале документа XML, иногда это делается в последующих его разделах. Декларация пространства имен применима к элементу, в котором она появляется, а также к потомкам этого элемента, даже если она не определена там явным образом. Имя может ссылаться на пространство имен, только если используется в области действия его декларации.
Однако нам потребуется также смешивать области действия пространств имен в элементах, которые в противном случае наследовали бы другие пространства имен. В связи с этим определены два способа декларации области действия- default (по умолчанию) и qualified (квалифицированный).
Как и следовало ожидать, необходимость добавления префикса к каждому имени в документе быстро становится утомительной. Фактически, введя концепцию области действия имени, мы можем смешивать в нашем документе большое количество префиксов. Если мы определяем пространство имен по умолчанию, то предполагается, что ему принадлежат все неквалифицированные имена внутри области действия его декларации. Таким образом, пространство имен, объявленное по умолчанию в корневом элементе, считается пространством по умолчанию для всего документа и может быть перекрыто только более специфическим пространством имен, объявленным внутри документа.
Чтобы пространство имен сделать пространством имен по умолчанию для некоторой области, достаточно опустить декларацию префикса.
Если префикс объявлен, а затем использован совместно с именем, то говорят что пространство имен явным образом установлено. Чтобы отнести к пространству имен неквалифицированное имя, необходимо объявить пространство по умолчанию, которое включает это неквалифицированное имя (без префикса).
Описанный выше метод работает хорошо, если вы можете четко разделить ваши пространства имен. Но иногда бывает необходимо включить в документ отдельные имена из внешних пространств имен. Вместо того чтобы декларировать пространства имен для целой области, можно использовать квалифицированные имена. Объявите нужные вам пространства имен в начале документа, а затем квалифицируйте их в месте использования.
DTD фактически представляют собой разновидность схемы. Однако, говоря о схемах, разработчики XML, как правило, имеют в виду замену DTD, написанную в соответствии с синтаксисом XML. В принципе, схемы можно считать механизмом создания ограничений, так как, хотя в них объявляются допустимые элементы или атрибуты, мы ограничиваем для пользователя выбор тегов и модели содержания.
Обычно схемы можно считать метаданными, или данными о данных, при разработке схем учитываются не только определения словаря, но и разъяснения связей между определенными типами данных.
Чтобы заменить определения DTD, надо предоставить, по крайней мере, те же возможности, которые предоставляют эти определения. Необходимо определять природу и структуру документов XML. Как и DTD, схемы представляют собой описание компонентов и правил словаря XML. Однако схемы уточняют DTD, позволяя точнее выражать некоторые концепции словаря. Кроме того, в схемах сделано несколько радикальных изменений. Используемый в них синтаксис полностью отличается от DTD. Они позволяют использовать имена из других схем, что решает проблему
Язык XML хорошо согласуется с определениями DTD. В то же время их активно пытаются усовершенствовать. Было выдвинуто множество предложений (некоторые из них доступны на сайте W3C как примечания), они, как это ни парадоксально, не помогают, а затрудняют принятие рекомендации, которая отражала бы наиболее распространенные особенности, требуемые от схем. В частности, многие разработчики настаивают на поддержке
У определений DTD имеется ряд недостатков, которые выявляются при углубленной работе с XML:
Синтаксис определений DTD отличается от языка XML. Он является расширенной Extended Backus Naur Form, ), и многие находят его трудным для чтения и использования. Предлагаемые схемы XML фактически, используют язык XML для описания определяемых ими языков, что устраняет необходимость изучения языка
Использование языка DTD. Разумеется, для DTD существуют специальные анализаторы. Он должен загрузить и прочитать DTD, после чего сможет проверить соответствующий документ на допустимость. К сожалению, не предусмотрена возможность обратиться к DTD из программы, использующей модель DOM. Объектная модель не позволяет получить доступ к метаданным словаря, написанным на языке DTD и сохранит его информацию для себя. Безусловно, было бы удобно, если бы DTD было написано на языке XML, так что мы могли бы исследовать их так же легко, как мы исследуем документы, написанные в соответствии с содержащимися в них правилами. Такая возможность позволила бы при помощи DOM изучить структуру обнаруженных нами словарей и даже модифицировать их правила
Определения DTD представляют собой фиксированную сущность. В них должны существовать все правила словаря. Все, что вам может понадобиться, вы размещаете в вашем словаре. Не создавая внешних объектов, вы не сможете использовать имена из других источников.
Создание и обслуживание ваших собственных подмножеств деклараций разметки станет значительно более удобным в результате использования ссылки на существующее определение. Вы не можете позволить авторам документа включать в него что-нибудь интересное впоследствии, если соответствующее определение отсутствует в DTD. Конечно, не всегда надо предоставлять авторам документов такую свободу, но было бы хорошо использовать части существующей схемы при проектировании нового словаря.
Поскольку все правила словаря должны находиться в DTD, вы не можете смешивать пространства имен. Хотя при помощи пространства имен можно ввести в документ тип элемента, нельзя ссылаться на декларацию элемента в DTD. При его использовании все его элементы должны быть объявлены в DTD.
Одним из существенных преимуществ языка XML является то, что все документы полностью пишутся при помощи общего типа данных - текста. Задачи программирования, однако, требуют использовать и другие типы. Определения DTD предлагают не много других типов данных, что является серьезным недостатком, когда XML применяют в приложениях определенного типа
Итак, определения DTD прекрасно позволяют определять структуры документов. Если учесть, что язык XML произошел от SGML, который также использует DTD, можно легко понять выбор этих определений в спецификации XML 1.0. Однако при использовании XML не только для разметки текста, но и в ситуациях, требующих программирования, описанные ранее ограничения становятся чрезвычайно важными.
В связи с необходимостью создания языка схем, призванного заменить и расширить DTD, было выдвинуто множество предложений. В их число входят:
RDFXML-DataDocument Content Description (DCD )Schema for Object-Oriented XML (SOX)Document Definition Markup Language ( DDML, ранее известный как XSchema )Ни один из этих проектов не был формально поддержан консорциумом W3C, тем не менее, каждый из них рассматривается консорциумом в процессе его работы над схемами XML.
Формат описания ресурсов (
Базовая модель RDF охватывает модель описательных данных, которую можно выразить на языке XML, а также и другие виды синтаксиса. Разработанные при помощи RDF схемы могут определять не только домена и структуры, но также делать выводы об отношениях между обсуждаемыми объектами. RDF - сложный язык, но он обладает большими выразительными возможностями, и поэтому его сложность оправдана.
RDF "стоит на трех китах": это ресурсы, свойства и утверждения.
Ресурсом может быть любая ощутимая сущность в концептуальном домене, на которую можно сослаться по идентификатору URI, в любом объеме - от целого сайта до одного элемента на странице HTML или XML. Это может быть даже объект, недоступный в сети Web, например, напечатанная книга.
Ресурсы типизированы; для определения категорий, из которых берутся специфические экземпляры ресурсов, используется система классов. Поддерживается наследование классов, так что разработчик может определить уровень описания от общего до узко специфического.
Говорят, что ресурсы имеют свойства, которые определяют и описывают их. На свойства налагаются ограничения, которые определяют их форму. Эти ограничения уточняют типы значений, которые могут быть присвоены свойству, и диапазон буквенных значений данного типа, которые могут быть выбраны.
Описав имена и структуры при помощи ресурсов и свойств, можно сформировать утверждения о концептуальном домене. Для этого составляются триплеты из ресурсов (подлежащих), свойств (сказуемых) и значений (дополнений). В специфических утверждениях значения могут быть литералами, а для мощных утверждений, охватывающих целые классы, они представляют собой ресурсы.
Может показаться, что для выполнения простого действия приходится затратить много усилий, но благодаря синтаксису можно делать утверждения о классах. Сделав в схеме больше утверждений, вы явным образом определите больший объем знаний о домене проблемы.
RDF - чрезвычайно мощный язык, допускающий использование выразительных и гибких утверждений. Он решает проблему недостаточной поддержки DTD, сильная типизация является центральной особенностью схемы RDF. Проектирование такой схемы, будучи трудоемким процессом, предполагает декларацию большого количества классов и свойств. Хотя возможность делать значимые утверждения была высоко оценена, она, вероятно, еще более мощная, чем это нужно для описания словарей XML.
Сказанное не означает, что эта возможность не требуется и в других ситуациях. Утверждения RDF позволяют формально описать факты в формате, поддающемся чтению компьютером. Как правило, разрабатываемые нами, словари XML неявным образом полагаются на общее понимание образующих их концепций окружающего нас реального мира. С помощью утверждений RDF мы, по крайней мере, теоретически, можем ввести достаточно информации, чтобы приложение само могло обнаружить дополнительные сведения о словаре. Это позволяет более эффективно использовать новый словарь и определять, в каких случаях он может быть применен к решаемой нами проблеме.
Однако для проектировщика, решающего задачи определения имен, структуры и связей, это может оказаться слишком большой нагрузкой.
Область применения стандарта XML-Data является более умеренной по сравнению с RDF.
Стандарт XML-Data различает синтаксические и концептуальные схемы. Хотя в обеих используется один и тот же язык, они освещают размечаемые нами данные с разных сторон.
Синтаксические схемы - это набор правил, предоставляющих процесс описания документов с помощью разметки; определения DTD являются примером таких синтаксических схем. Синтаксические схемы XML-Data налагают сходные с DTD ограничения на структуру словаря.
Концептуальные модели описывают связи между понятиями или объектами и, как таковые, они идеальны для моделирования реляционных баз данных. При помощи схем XML-Data можно установить связи, основанные на том, что книги содержат заголовки и цены. Это делается способом, отличающимся от синтаксиса любого документа XML. Новый стандарт предназначается для того, чтобы расширить область применения языка XML, включив в него информацию о реляционных базах данных. Главные связи, выраженные ключами в реляционных базах данных, можно формально выразить также и в схемах XML-Data.
XML Data содержит интересные возможности, делающие его более мощным чем DTD:
В языке XML-Data для конструирования схем используется словарь XML, что дает пользователям возможность читать и записывать схемы, не осваивая предварительно новый синтаксис. Это также дает возможность изучать схему или динамически создавать новую при помощи модели DOM и существующих анализаторов.
Язык XML-Data поддерживает DTD. Это могут быть базовые типы, определенные в пространстве имен типов данных, или комплексные пользовательские типы, содержащиеся в схеме, предоставляемой проектировщиком. Приложение больше не должно понимать тип данных элемента или атрибута и перед использованием данных преобразовывать строки или текст в соответствующий формат. Требуемую информацию можно явным образом определить в схеме, а анализаторы выполнят преобразование по желанию приложения.
Язык XML-Data позволяет налагать ограничения на диапазон значений, принимаемых элементами и атрибутами, такие как минимальное и максимальное значения. Эта возможность часто бывает, полезна при проверке допустимости документов XML.
Механизмом, позволяющим повторно использовать элементы, является поддерживаемое языком XML Data наследование типов. Он позволяет выявлять и расширять элементы при описании объектов проблемы, решить которую мы пытаемся с помощью XML. Мы можем написать, например, некоторые общие надтипы, а затем уточнять их в более специфические классы элементов, добавляя или заменяя новые члены в декларации надтипа. В определениях DTD таким же способом используются сущности ( entities ), но наследование типов формализует процесс. Не имея формальной семантики, сущности могут быть использованы неверно, настолько, что это затруднит, а не облегчит работу пользователя. Формальный механизм наследования дает возможность повторного использования, сохраняя при этом некоторый контроль над реализацией этой возможности.
Еще одной мощной возможностью языка XML-Data являются так называемые открытые и закрытые модели содержания. Классическое определение DTD представляет собой закрытую модель. Соответствующие ей документы должны придерживаться правил и не могут содержать ничего, что не соответствует правилам, поскольку все они должны быть описаны в DTD.
Если схема открыта, то соответствующие ей документы могут содержать и другую информацию, не объявленную в DTD. Соответствующая схеме часть документа должна подчиняться заложенным в ней правилам, но мы можем включать в него и другие пункты без ограничений со стороны текущей схемы. Эти пункты могут быть описаны в другой схеме, а могут быть, вообще, никак не ограничены. Можно использовать специальные значения. С точки зрения нашей дискуссии, более важно то, что документы открытой модели представляют собой способ, позволяющий смешивать пространства имен. Фрагмент информации, соответствующий одной схеме, можно включить в середину документа, соответствующего другой. Более того, можно явным образом объявить, что для конкретных элементов используется открытая или закрытая модель содержания. Для этого существует атрибут content, значением которого по умолчанию является open.
ID и IDREFВ языке XML-Data конструкции ID и IDREF расширяются отношениями. В отношении один элемент используется в качестве ключа или индекса для содержания другого элемента. Это непосредственно применимо к моделированию первичных и внешних ключей в реляционных базах.
Предложение Document Content Description ( XML-Data. Это предложение представляет собой словарь RDF, явным образом предназначенный для декларации словарей XML. Его разработчики использовали выразительную мощь одного из стандартов представления метаданных - RDF - для создания стандарта с более ограниченной областью применения. Приблизительно это напоминает то, что язык XML является упрощенным множеством SGML.
Язык XML-Data, хотя в нем и отсутствуют некоторые углубленные возможности последнего. Он строго ориентирован на определение словарей XML. Однако в этом языке сохраняется характерная для XML-Data поддержка XML-Data, XML-Data, XML-Data, позволяет налагать ограничения на значение содержания элементов.
Основанный на языке RDF, DTD. Можно сказать, что в нем широкая мощность языка обменивается на направленную простоту. DTD и отказывается от их углубленной проработки, чтобы получить легко реализуемый стандарт схем XML.
Все, что можно было описать с помощью DTD, содержится в части стандарта XML Schema, посвященного структурам. Поскольку схемы пишутся в соответствии с синтаксисом XML, структуры ссылаются на конструкции на этом языке, при помощи которых можно определять разметку. Это означает, что структуры представляют собой еще одно приложение XML (словарь XML для описания классов документа XML) и как таковое могут использовать схемы для описания самих себя.
Итак, раздел схем спецификации представляет собой ту ее часть, в которой определены элементы и атрибуты для описания схем. Что более важно, в этой части описана модель содержания для элементов. Такая модель явным образом определяет допустимую внутреннюю структуру элементов. Структуры являются сердцем схем XML.
В окружающем нас мире широко используются концепции чисел, строк и множеств, так что написанные на современных языках программы поддерживают большое количество тщательно проработанных систем встроенных типов данных и процедуры по определению новых типов. Добавление типов данных в проект XML Schemas станет важным подспорьем для программистов, использующих XML при работе с данными в своих приложениях. Такая поддержка типов данных предусматривает возможность проверять допустимость значения в документе, а также осуществлять преобразование из текстовой формы во встроенный тип при обработке документа XML. Таким образом, чтобы использовать документы XML в качестве основы для интеграции программ и систем, необходимо иметь возможность перехватывать (определять) типы данных размечаемой нами информации.
Это обеспечивает вторая часть спецификации XML Schemas, носящая название XML Schemas: Datatypes. Она позволяет не только перехватывать базовые типы данных, но и записывать ограничения, налагаемые на данные в домене нашей проблемы. Она позволяет записывать числовые границы, множества и упорядоченные списки, а также создавать маски для допустимых строковых представлений наших данных.
Типы данных схем имеют набор четких значений, называемый пространством значений ( value space ). Он представляет собой абстрактную коллекцию значений, которые может принимать тип. Например, множество целых чисел является пространством значений для типа integer. Это пространство характеризуется ограничивающими свойствами и операциями над значениями в нем.
Часть XML Schema: Datatypes целиком посвящена вопросам определения пространств значений, а затем перечислению ограничивающих свойств типа. Он содержит множество примитивных типов данных и предоставляет механизм генерации новых типов на их основе. В проект входит большое количество таких генерированных типов, находящих широкое применение, но его составители приветствуют создание собственных типов, предназначенных для использования в конкретном приложении.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.