Расширяемый язык разметки XML

Автор работы: Пользователь скрыл имя, 14 Октября 2013 в 23:51, курсовая работа

Описание работы

В 1996 году консорциумом Word Wide Web, была предпринята попытка, приступить к проектированию расширяемого языка разметки, который сочетал бы в себе гибкость и мощность языка SGML и совместимый с распространенностью HTML. Этот язык получил название (Extensible Markup Language) XML. А в феврале 1998 был принят стандарт этого языка как XML 1.0 в качестве рекомендаций W3C. В настоящий момент существует выпущенная 6 октября 2000 года Extensible Markup Language (XML) 1.0 (Second Edition) рекомендация консорциума W3C.

Содержание работы

Введение……………………………………………………………………стр.2
1.Расширяемый язык разметки XML……………………………………стр.3
1.1. Достоинства…………………………………………………………...стр.3
1.2. Недостатки………………………………………………………….....стр.5
1.3. Отображение XML во Всемирной паутине………………………...стр.6
1.4. Словари XML………………………………………………………....стр.7
2. Структура XML-документа……………………………………………стр.7
2.1. Конструкции языка…………………………………………………...стр.9
2.2. Моделирование XML-документов…………………………………стр.11
3. Схемы данных…………………………………………………………стр.19
Заключение………………………………………………………………стр.27
Список использованной литературы……………………………………

Файлы: 1 файл

курсовая по языку XML.docx

— 172.10 Кб (Скачать файл)

Рисунок 1

      1. Словари XML

Так как XML является достаточно абстрактным языком, были разработаны словари XML.

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

Были созданы  более специализированные словари, например протокол передачи данных SOAP, который не является человеко-ориентированным и достаточно трудно читаем. Есть коммерческие словари, такие как CommerceML, xCBL и cXML которые используются для передачи данных, ориентированных на торговую деятельность, эти словари включают в себя описание системы заказов, поставщиков, продуктов и прочее.

Обычно, описывая какой-либо документ, человек для себя придумывает  некоторый словарь, который потом  описывается посредством DTD или просто объясняется «на пальцах» заинтересованным лицам.

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

 

2. Структура XML-документа

Хотя XML, сильно отличается по своим  возможностям и предназначению от языка  гипертекстовой разметки, оба эти  языка являются подмножествами SGML, и, следовательно, наследуют его  базовые принципы.

Любой XML-документ оформляется  согласно следующей структуре:

Рисунок 2. Структура XML-документа.

Т.е. состоит из трёх разделов:

  • Пролог
  • Тело документа
  • Эпилог (на рис.1 выше не представлен.)

Пролог. 

Любой XML документ начинается с пролога. В пролог помещается описательная информация для всего документа  в целом, которую требуется получить анализатору ещё до начала какой-нибудь обработки документа. К ней относятся:

  • Команды обработки
  • Декларация типа документа
  • Комментарий

Пролог не является обязательной частью XML-документа, в том смысле, что его отсутствие не должно вызывать каких-нибудь проблем у анализаторов. Необязательность пролога продиктована лишь совместимостью с GML и HTML в версиях, существовавших до выхода XML. Если бы пролог был обязателен, то документы в GML и HTML прежних версиях перестали бы быть хорошо оформленными (объясняется ниже). Однако, правилом хорошего тона считается всегда помещать пролог в любой XML-документ.

Пролог организационно включается в Корень документа.

Тело документа. 

Тело документа собственно и включает в себя прикладную информацию и должно состоять ровно из одного узла, называемого элементом документа (element document). С точки зрения иерархической структуры данных, все другие прикладные данные обязаны быть детьми одного единственного элемента документа (См. таже раздел Элемент данного документа).

Тело документа организационно включается в Корень документа.

Эпилог. 

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

Корень документа. 

Организационно, и Пролог и Тело документа включаются в так называемый Корневой узел или Корень документа, который обычно обозначают одиночным символом деления: '/'. Любой анализатор начинает разбор XML-документа именно с этого корневого узла. Так что реальная схема документа может быть представлена следующим образом:

Рисунок 3. Иерархическая структура XML-документа.

.

2.1. Конструкции языка

Содержимое XML-документа представляет собой набор элементов, секций CDATA, директив анализатора, комментариев, спецсимволов, текстовых данных.

  • Элементы данных

Элемент - это структурная единица XML-документа. Заключая слово rose в в тэги , мы определяем непустой элемент, называемый , содержимым которого является rose. В общем случае в качестве содержимого элементов могут выступать как просто какой-то текст, так и другие, вложенные, элементы документа, секции CDATA, инструкции по обработке, комментарии, - т.е. практически любые части XML-документа. Любой непустой элемент должен состоять из начального, конечного тэгов и данных, между ними заключенных.

Например, следующие фрагменты  будут являться элементами:  
rose 
Saratov

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

 

, .

  • Комментарии

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

  • Атрибуты

Если при определении элементов  необходимо задать какие-либо параметры, уточняющие его характеристики, то имеется возможность использовать атрибуты элемента. Атрибут - это пара "название" = "значение", которую  надо задавать при определении элемента в начальном тэге.

 

Пример:

#ff08ff

white

или

Ivan Petrov

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

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

  • Директивы анализатора

Инструкции, предназначенные для  анализаторов языка, описываются в XML документе при помощи специальных  тэгов - и ?>;. Программа клиента использует эти инструкции для управления процессом разбора документа. Наиболее часто инструкции используются при определении типа документа (например, ) или создании пространства имен.

  • CDATA

Чтобы задать область документа, которую  при разборе анализатор будет  рассматривать как простой текст, игнорируя любые инструкции и  специальные символы, но, в отличии  от комментариев, иметь возможность  использовать их в приложении, необходимо использовать тэги . Внутри этого блока  можно помещать любую информацию, которая может понадобится программе- клиенту для выполнения каких-либо действий (в область CDATA, можно помещать, например, инструкции JavaScript). Естественно, надо следить за тем, чтобы в области, ограниченной этими тэгами не было последовательности символов ]].

    1. Моделирование XML-документов

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

Модель определяет документы, которые  можно создать с помощью языка; или, в рамках терминологии XML, модель документа устанавливает, какие  документы согласуются (conform) с языком. Модель документа отвечает на такие вопросы, как «Может ли быть заголовок у данного элемента?» или «Должна ли быть указана цена для этого элемента?» Модель является документом особого рода, написанным по правилам синтаксиса, предназначенного для описания языков XML, и явно описывает грамматику и словарь отдельного языка разметки. Иногда язык, который она описывает, называют типом документа (document type) или приложением XML (XML application). С помощью такой модели можно определить, согласуется ли некоторый документ XML с данным типом документа.

Фактически написанные кем-то документы, называемые экземплярами документа (document instances), могут согласоваться с языком, описанным в модели документа или не согласоваться. Согласующиеся документы называют действительными (valid) в контексте языка; другие документы называют недействительными (invalid).

Модель документа может быть лишним грузом, если надо сопровождать лишь один-два документа, но если документов много, а требования к качеству высоки, ее создание может окупиться. Вот  некоторые ситуации, в которых  модель документа в состоянии  облегчить жизнь:

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

Рисунок 4

  • выступать в качестве данных в средах создания структурированных документов, например, в редакторе XML. В такой программе редактор может автоматически вставлять необходимые поля и предлагать разработчику документа списки допустимых групп элементов.
  • Разработчику нужна надежная структура для развивающегося языка или семейства языков. Модель документа предоставляет простой способ создания стандарта, такого, например, как HTML Version 4.0. Отслеживание новых версий языка жизненно важно для программ XML, поскольку старые программы могут оказаться несовместимыми с более новыми версиями языка. Модели документов можно объединить для создания составных языков. Например, DocBook использует модель таблиц CALS, а не пытается определить свою.

Конечно, могут быть основания и  не использовать модель документов. Сопровождение  модели может оказаться неудобным, особенно в начале, когда язык подвергается тестированию и дальнейшей разработке. Она может замедлить обработку, например, если браузеры XML должны загружать  модель документа из сети. Наконец, наличие авторитарной модели, указывающей, какие элементы можно использовать, а какие – нет, может просто сломать стиль работы. А, кроме  того, нужно потратить силы на то, чтобы разработать модель или  найти готовую, отвечающую потребностям. В конечном счете, автор сам решает, использовать модель документа или  нет: XML спроектирован так, что позволяет работать в любом случае.

  • Documents Type Definitions (DTD)

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

...  
...

]>  
...

В том случае, если используются одновременно внутренние и внешние описания, то программой-анализатором будут сначала  рассматриваться внутренние, т.е. их приоритет выше. При проверке документа XML-процессор в первую очередь  ищет DTD внутри документа. Если правила  внутри документа не определены и  не задан атрибут standalone ="yes" , то программа загрузит указанный внешний файл и правила, находящиеся в нем, будут считаны оттуда. Если же атрибут standalone имеет значение "yes", то использование внешних DTD описаний будет запрещено.

Информация о работе Расширяемый язык разметки XML