Вложение элементов


Содержание

XML. Основные понятия и конструкции языка

XML (eXtensible Markup Language — расширяемый язык разметки) — рекомендованный Консорциумом Всемирной паутины язык разметки, фактически представляющий собой свод общих синтаксических правил. XML — текстовый формат, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML), иногда называемых словарями. XML является упрощённым подмножеством языка SGML.

Целью создания XML было обеспечение совместимости при передаче структурированных данных между разными системами обработки информации, особенно при передаче таких данных через Интернет. Словари, основанные на XML (например, RDF, RSS, MathML, XHTML, SVG), сами по себе формально описаны, что позволяет программно изменять и проверять документы на основе этих словарей, не зная их семантики, то есть не зная смыслового значения элементов. Важной особенностью XML также является применение так называемых пространств имён (namespace).

XML-документа состоит из вложенных элементов, некоторые из которых имеют атрибуты и содержимое. Элемент обычно состоит из открывающего и закрывающего тегов, обрамляющих текст и другие элементы. Открывающий тег состоит из имени элемента в угловых скобках, например, « »; закрывающий тег состоит из того же имени в угловых скобках, но перед именем ещё добавляется косая черта, например, « ». Содержимым элемента называется всё, что расположено между открывающим и закрывающим тегами, включая текст и другие (вложенные) элементы.

Кроме содержания у элемента могут быть атрибуты — пары имя-значение, добавляемые в открывающий тег после названия элемента. Значения атрибутов всегда заключаются в кавычки (одинарные или двойные).

Каждый XML-документ должен содержать в точности один корневой элемент. В отличие от HTML, теги в XML чувствительны к регистру.

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

· Имена могут состоять из букв цифр и других символов

· Имена не могут начинаться с цифры или знака препинания

· Имена не должны начинаться со последовательности xml (или XML, или Xml и т. д.)

· Имена не могут содержать пробелов

Сергей
Наталья
Напоминание
Не забудь про наши планы на эти выходные!

Вложение элементов

Автор: Дэвид Мертц (David Mertz)
Перевод: Intersoft Lab
Авторские права: market@iso.ru

Вопросы проектирования XML-форматов

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

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

Важно помнить о различии между XML-документами, которые должны быть просто корректно оформлены, и теми, что обязаны быть допустимыми согласно некоторому DTD/Схеме. Допустимость является гораздо более строгим критерием: с ее помощью можно потребовать, чтобы были представлены определенные данные, и чтобы они были структурированы заданным образом. Именно по этой причине приходится прикладывать гораздо больше усилий для того, чтобы процесс создания заданного документа соответствовал условиям допустимости. У обоих подходов имеются свои преимущества; использование DTD усложняет задачу выбора элементов/атрибутов, но у обоих случаях есть свои плюсы и минусы. Ниже рассмотрены эти две альтернативы.

Важен ли порядок следования данных

Использование DTD гарантирует, что вложенные элементы, в отличие от атрибутов, будут строго упорядочены. В только корректно оформленных XML-документах можно свободно манипулировать порядком — в этом случае любой тег может находиться внутри любого другого тега, на любом уровне вложенности. В обоих случаях атрибуты обычно лучше подходят для неупорядоченных данных. Однако, если речь идет о XML-документах с DTD, использование атрибутов едва ли не обязательно для этого типа данных.

Рассмотрим, например, список контактов (контактной информации), каждый из которых должен включать имя, возраст и номер телефона. Разумеется, с точки зрения логики, данные о возрасте не должны обязательно предшествовать номеру телефона. Поэтому, атрибуты и неупорядочены, и потому являются более интуитивным выбором. Сравните два небольших XML-документа, приведенные в Листингах 1 и 2:

Листинг 1. Использование атрибутов для передачи контактной информации

Листинг 2. Использование вложенных элементов для передачи контактной информации

Теперь представим, какой DTD может быть задан для каждого из этих XML-форматов. Для Листинга 1, демонстрирующего использование атрибутов, это мог бы быть следующий DTD:

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

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

Листинг 4. DTD для документа с использованием вложенных элементов

Очевидный недостаток DTD, приведенного в Листинге 4, состоит в том, что этот простой пример (Листинг 2) является недопустимым согласно этому DTD. Дело в том, что порядок вложенных элементов нарушен. В таблице справа показано, как можно использовать неупорядоченные вложенные элементы с DTD, хотя, если не имеется иных непреодолимых причин, лучший выбор — воспользоваться заданием атрибутов для передачи неупорядоченных данных.

Возможность нахождения многочисленных данных на одном уровне

Если одни и те же данные неоднократно повторяются в пределах объекта, вложенные элементы несомненно предпочтительней. Например, в рассмотренном выше примере объект contacts содержит множество объектов contact . Понятно, что в этом случае каждый контакт должен быть описан в элементе-потомке элемента contacts .

Однако, в реальной жизни при внесении изменений разработчики часто уходят от этого принципа проектирования. Рассмотрим, как это может происходить: сначала вы определяете, что у каждого Flazbar имеется прикрепленный к нему flizbam (а flizbam описывается одной величиной). Кажется вполне разумным сберечь дополнительное наполнение вложенных элементов и создать атрибут flizbam для тега Flazbar . Однако, затем — после того, как вы уже написали великолепный рабочий код для обработки несколькими Flazbar — вы узнаете, что в некоторых случаях у Flazbar могут быть два flizbam. Но это не проблема: вы вносите незначительные изменения в установленный код и просто переписываете DTD:

После исправления кода ваши старые XML-документы по-прежнему допустимы, и новые работоспособны. Немного погодя вы обнаруживаете, что у Flazbar может быть третий flizbam.

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

Моделирование неупорядоченных вложенных элементов

Для того, чтобы XML-документ, представленный в Листинге 2, был допустимым, в DTD следует добавить следующее определение:

DTD, которое очень гибко определяет вложенные элементы, содержащие контактную информацию Однако, приведенное выше DTD предусматривает слишком большую гибкость. В этом случае у элементов contact могут отсутствовать элементы name, а также быть несколько элементов age, что нарушает семантические требования. Для того, чтобы решать поставленную задачу, потребовалось бы чрезвычайно громоздкое определение, приведенное ниже:

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

Обязательность сохранения свободного места

После выполнения нормализации атрибутов можно рассчитывать, что каждый атрибут отделен от своих соседей пробелом. Но это — все, на что можно рассчитывать. Для удобства чтения можно, не опасаясь осложнений, добавить вертикальное или горизонтальное свободное место к длинным значениям атрибутов (на самом деле это необходимо делать). Но если эти удобочитаемые атрибуты пойдут через XML-парсер, компоновка атрибутов, вероятно, будет несколько отличной от первоначальной, находящейся в исходном XML.

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

Важность удобочитаемости


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

Лично мне гораздо легче читать и писать атрибуто-ориентированные XML-форматы, а не ориентированные на вложенные элементы. Чтобы пояснить сказанное, вернемся к Листингам 1 и 2. Ни один из них не так уж сложно читать, но Листинг 2 [1] , который демонстрирует подход, основанный на использовании атрибутов — проще, его также легче писать, поскольку не нужно озадачиваться проблемой непостоянства порядка следования вложенных элементов.

Заключение

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

Ресурсы

  • Все, что действительно необходимо знать о XML, это Рекомендация W3C «Расширяемый язык разметки (XML) 1.0» (Extensible Markup Language (XML) 1.0). Разумеется, чтобы понять, какое она имеет значение, требуется немного проницательности.
  • В рубрике XML Cover Pages приводятся рекомендации по «Использованию элементов и атрибутов» (Using elements and attributes). На этой странице также можно найти ссылки на ряд статей, в которых предлагаются взаимопротиворечащие рассуждения о том, что выбрать атрибуты или элементы. Именно по этой причине мы, программисты, и «получаем наш длинный доллар»!
  • Еще один способ понять различие между атрибутами и элементами — это изучить материалы «Форматы, основанные на документах, или форматы, основанные на данных» («Document-Centric» vs. «Data-Centric»).
  • Познакомьтесь с другими статьями колонки «Советы о XML» (XML tips), публикуемыми в разделе developerWorks XML.

Об авторе

Дэвид Мертц использует абсолютно неструктурированный интеллект, чтобы писать о форматах структурированных документов. Дэвид доступен по адресу: mertz@gnosis.cx, а жизнь его описана на http://gnosis.cx/publish/.

[1] По всей видимости, это опечатка (в оригинале стоит Listing 2): и вместо Листинга 2 должен быть Листинг 1 (прим. пер.)

Синтаксис и основные понятия языка XML, создание валидных документов

Понятие о языке XML

XML — это расширяемый язык разметки (Extensible Markup Language), разработанный специально для размещения информации в World Wide Web, наряду с HTML, который давно стал стандартным языком создания Web-страниц. В отличие от HTML, вместо использования ограниченного набора определённых элементов вы имеете возможность создавать ваши собственные элементы и присваивать им любые имена по вашему выбору. Примечание: подразумевается, что читатель данной статьи хотя бы очень поверхностно знаком с языком HTML.

XML решает ряд проблем, которые не решает HTML, например:

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

В зависимости от уровня соответствия стандартам документ может быть «верно сформированным» («well-formed»), либо «валидным» («valid»). Вот несколько основных правил создания верно сформированного документа:

  • Каждый элемент XML должен содержать начальный и конечный тэг (либо пустой тэг типа , который может нести информацию посредством своих атрибутов).
  • Любой вложенный элемент должен быть полностью определён внутри элемента, в состав которого он входит.
  • Документ должен иметь только один элемент верхнего уровня.
  • Имена элементов чувствительны к регистру.

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

  • Каскадная таблица стилей (Cascading Style Sheet — CSS) или расширяемая таблица в формате языка стилевых таблиц (Extensible Stylesheet Language — XSL).
  • Связывание данных. Этот метод требует создания HTML-страницы, связывания с ней XML-документа и установления взаимодействий HTML-элементов с элементами XML. В дальнейшем HTML-элементы автоматически отображают информацию из связанных с ними XML-элементов.
  • Написание сценария. Этот метод требует создания HTML-страницы, связывания с ней XML-документа и получение доступа к XML-элементам с помощью кода сценария JavaScript или VBScript.

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

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

Простейший XML-документ

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

  • Объявление типа документа.
  • Одну или несколько инструкций по обработке.

XML-документ может содержать комментарии, начинающиеся с символов » «. Комментарий может содержать любой текст, за исключением символов «—«. Тексты комментариев доступны для написанного внутри HTML-страницы кода сценария.

XML-документ можно набрать в любом текстовом редакторе, сохранив документ как текстовый файл с расширением .xml. В дальнейшем такой документ будет открываться двойным щелчком в Internet Explorer. Вот пример простейшего XML-документа:

XML элементы

XML документ состоит из XML элементов.

Что такое XML элемент?

XML элемент — это все от (и включая) начального тега элемента до (и включая) конечного тега элемента.

Элемент может содержать:

  • другие элементы
  • текст
  • атрибуты
  • или набор из всего выше названного

В приведенном выше примере и содержат элементный контент, состоящий из других элементов. Также, у есть атрибут (category=»CHILDREN»). У элементов , , и

есть текстовый контент.

Пустые XML элементы


При написании элементов без контента можно использовать альтернативный синтаксис.

Вместо того, чтобы писать пустой элемент в виде:

Такой синтаксис элемента называется самозакрывающийся.

Правила написания имен XML

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

  • Имена могут содержать буквы, числа и другие символы
  • Имена не могут начинаться с цифры или символа пунктуации
  • Имена не могут начинаться с сочетания «xml» (или XML, или Xml и т.п.)
  • Имена не могут содержать пробельные символы

В качестве имен можно использовать любые слова. Нет зарезервированных слов.

Хорошая практика составления имен

Старайтесь придумать описательные имена: , .

Имена следует составлять короткие и простые, вроде: ; а не: .

Избегайте символ «-«. Если вы напишите нечто вроде «first-name», то некоторые приложения могут решить, что вы вычитаете имя «name» из имени «first».

Избегайте символ «.». Если вы напишите нечто вроде «first.name», то некоторые приложения могут решить, что «name» это свойство объекта «first».

Избегайте символ «:». Двоеточие зарезервировано для механизма пространства имен.

Не-латинские символы, вроде, éòá вполне легальны в XML, однако, если некое приложение их не поддерживает, то возникнут проблемы.

Стили написания имен

Для XML элементов не существует какого-либо определенного стиля написания имен. Тем не менее, вот несколько наиболее часто используемых стилей:

Стиль Пример Описание
Нижний регистр Все буквы в нижнем регистре
Верхний регистр Все буквы в верхнем регистре
С символом подчеркивания Слова разделяются символом подчеркивания
В стиле Pascal Первые буквы всех слов в верхнем регистре
«Верблюжий горб» Первые буквы всех слов за исключением первого в верхнем регистре

Если вы выбрали какой-либо стиль написания имен, то следует последовательно придерживаться его!

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

Расширяемость XML элементов

XML элементы могут быть расширены, чтобы нести больше информации.

Взгляните на следующий пример:

Давайте представим, что мы создали приложение, которое извлекает элементы , и из XML документа и формирует следующее сообщение:

Представьте, что автор XML документа добавил некоторую дополнительную информацию:

Прервется ли работа нашего приложения?

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

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

IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов.

Разметка XML документа. XML атрибуты. Корень XML документа. Декларации в XML. Комментарии в XML. Синтаксис XML документа

Здравствуйте, уважаемые посетители моего скромного блога для начинающих вебразработчиков и web мастеров ZametkiNaPolyah.ru. Сегодня продолжаем говорить о расширяемом языке разметки XML, продолжим разговор о XML тегах, рассмотрим, как писать сокращенные XML теги, поговорим о кодировки в XML документах, так же рассмотрим, что такое корневой элемент или иначе корень XML документа, в этой публикации мы рассмотрим вопрос о комментариях в XML документах, а так же посмотрим какие символы запрещены в XML. Рассмотрим, что такое декларация, а так же для чего нужна декларация в XML документе и как правильно декларировать. Так же мы поговорим, о разметки XML документа. И так, продолжаем разговор о синтаксисе XML документа, начатый в статье Расширяемый язык разметки XML. Синтаксис XML. Структура XML документа. Применение XML.

Синтаксис XML документа, как декларировать XML документ, из чего состоит XML документ. Инструкции XML документа.

В первой статье, я как смог, так и объяснил, что такое синтаксис вообще и в XML документе в частности. Теперь предлагаю более подробно остановиться на данном вопросе, а так же рассмотреть, что такое декларация в XML и как декларировать XML документ. Синтаксис в XML на самом деле очень сложный, шаг влево, шаг в право и XML парсер вас уже не поймет.

Для начала, давайте рассмотри из чего состоит XML документ и соответственно рассмотрим синтаксис XML документа.

Пример XML документа:

Любой XML документ начинается с пролога или декларации. Что такое пролог в XML документе или иначе декларация XML документа — это начало XML документа, в примере это первая строка, как правило показывается, что это XML документ и указывается версия XML, а так же кодировка XML документа( ), на данный момент уже есть XML версии 1.1.

Обратите внимание на конструкцию пролога, так как в XML все очень жестко и структурировано, а именно на начало декларации( Пример процессинговых инструкций в XML документе:

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

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

XML комментарии, как правильно писать комментарии в XML документе.

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


Естественно, чаще всего используются для того, что бы оставлять для себя и кого-то другого какие-то пометки и указания по самому XML документу. Синтаксис комментариев в XML, такой же как и в HTML комментариях, начинается комментарий с конструкции

style = «text-align: justify;» >

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

XML теги и XML элементы, правила написания XML тегов.

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

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

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

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

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

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

XML атрибуты, как правильно писать XML атрибуты

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

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

Единицы измерения XML. Корневой XML элемент или корень XML документа.

В XML существует очень важное правило, минимальной единицей измерения является документ, один XML элемент это документ, и этот XML элемент является минимальной единицей измерения — всегда! Как это можно понять? XML документ всегда состоит из одного тега или элемента, по буржуйски этот тег называется root или корень XML документа, это означает, что у любого документа должен быть всегда один элемент(один тег), внутри него может быть все, что угодно, но один XML элемент в XML документе должен быть всегда.

В первом нашем примере корневым элементом является, элемент

, внутри него можно размещать все, что угодно, делать какие угодно ветвления и вложения, но создавать элемент уровня

Пример того как можно составлять XML документ:

В данном примере, элементы woman и man лежат внутри корневого XML элемента people, поэтому здесь ничего не нарушено и XML документ составлен правильно.

Пример того как нельзя составлять XML документ:

Данный пример по своей сути не правильный и XML обработчик выдаст ошибку, так как у XML документа может быть только один корневой элемент, а в данном примере их два, это people и animal, что противоречит стандарту XML. Еще раз повторюсь, у XML документа может быть только один корневой элемент, внутри которого должны располагаться все остальные элементы. Если же вы все-таки напишите два корневых элемента, анализатор вам так и скажет, «В XML документах, допускается один элемент верхнего уровня».

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

Так писать XML документы нельзя:

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

Пример пустого XML документа:

Данный документ пустой и содержит один элемент(tag), то есть корень XML документа, поэтому он удовлетворяет XML стандарту. XML документ это всегда один главный тег, то есть все прологи, процесинговые инструкции, это все не так важно, XML документ — это один тег.

Типы данных в XML. CDATA и PCDATA.

Как я уже говорил, XML работает только с данными, в чистом XML данные одни — текст. XML документ состоит из элементов, внутри которых расположены текстовые данные. Любые данные находящиеся внутри XML документа рассматриваются как PCDATA (Parsed Character Data), это означает, что XML анализатор будет рассматривать данные, как парсируемые, анализируемые текстовые данные, то есть XML парсер анализирует не только теги и атрибуты, но и то что находится внутри них.

С одной стороны это удобно, но допустим если у вас появится желание поместить внутрь XML элемента пример 3+4>2, у вас это не получится, так знак «>» запрещенный символ, всего в XML три запрещенных символа ( , &). И если анализатор XML встретит эти символы внутри элемента, он будет их анализировать и естественно ругаться, говоря что вы допустили синтаксическую ошибку.

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

Все, что размещено в этой конструкции( ), анализатор будет считать обычным текстом и не будет обращать на него внимание. Правильно эта конструкция называется секция CDATA, то есть раздел непарсируемых данных.

Пролог в XML документе. Кодировка XML документа. Русские XML теги. Кодировка Unicode.

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

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

Причем, после того, как вы укажете кодировку, символы из этой кодировки вы можете использовать любые и в любом месте XML документа, в название тегов, атрибутов, значений атрибутов, сами данные и так далее. Кодировку для XML документа, я бы посоветовал использовать UTF-8. Сейчас объясню почему.

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

Unicode, на самом деле один, но у него есть множество способов кодирования. UTF — это способ кодирования файлов. И вот этих UTF много, порядка 10 штук, можете поискать(UTF-7, UTF-8, UTF-16, UTF-32), цифра показывает минимальное число бит на один символ.

И так, нам необходимо указывать кодировку своих документов, причем указывать и для редактора и для анализатора, хорошо, если вы используете какой-нибудь Notepad++, где вы явно указываете кодировку и нет никаких проблем, а если вы используете обычный блокнот windows.

Предлагаю попробовать создать пустой документ, с расширением txt в обычном блокноте. И затем его сохранить. Размер этого документа будет ноль байт.

А теперь попробуйте пересохранить этот же пустой документ, но уже в кодировки Unicode, я выберу способ кодирования UTF-8, а теперь посмотрите, какой размер будет у пустого файла в кодировки UTF-8. Документ в кодировки UTF-8 будет весить 3 байта, но откуда взялись эти 3 байта, в документе по прежнему ничего нет, он пустой.


Так вот, блокноту нужно как-то подсказывать, какая кодировка используется, для этих целей в Unicode придумали Byte Order Mark, или сокращенно BOM, это метка порядка чередования байтов. Идея разработчиков Unicode очень проста. Поскольку в Unicode миллиарды различных символов, включая полную типографику, в которой только с десяток символов пробелов(узкий пробел, широкий пробел, неразрывный пробел, широкий пробел с переносом, неразрывный пробел и так далее). Среди множества этих пробелов есть один хитрый пробел, который называется неразрывный непечатный пробел, он применяется для разделение частей многосложных слов, его невидно, но он есть, как суслик, ты его не видишь, а он есть.

И не менее хитрые разработчики Unicode придумали такую штуку, если файл начинается с неразрывного непечатного пробела, программа поймет, во-первых, что вы используете Unicode, а во-вторых, способ кодирования. Неразрывный непечатный пробел и есть BOM, метка, которая показывает какую кодировку вы используете, а при способе кодирования UTF-8 неразрывный непечатный пробел кодируется тремя байтами, поэтому наш пустой документ имеет размер три байта.

Так вот, если этот BOM есть, любая виндовая программа определит, что документ закодирован в Unicode. Некоторые Unix интерпретаторы косячат, когда видят BOM, поэтому старайтесь кодировать все свои документы(не только XML) без BOM.

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

XML подведение итогов. Well-formed document или хорошо сформированный XML документ.

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

Так же мы поговорили про анализатор XML, который прежде чем, что-то делать с документом проверяет его и в случае малейшей ошибки должен отказаться от работы с XML документом. Well-formed document — это первый уровень правильности написания XML документа, грубо говоря — это соблюдение всех синтаксических правил.

Любой XML документ считается синтаксически правильно сформированным, если выполняются следующие синтаксические правила в XML документе:

  1. Документ XML соответствует своей кодировке и кодировка указанна внутри XML документ.
  2. XML документ имеет только один корневой элемент.
  3. Все элементы внутри корня XML документа корректно закрыты и вложены.
  4. Правильно соблюден регистр имен элементов и деклараций
  5. Значение XML атрибутов заключены в двойные кавычки.
  6. Внутри одного тега нет повторяющегося атрибута, один и тот же атрибут два раза в одном теге находиться не могут

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

На этом всё, спасибо за внимание, надеюсь, что был хоть чем-то полезен и до скорых встреч на страницах блога для начинающих вебразработчиков и вебмастеров ZametkiNaPolyah.ru

    Возможно, вам будет интересно:

Интеграция XML данных — другой путь

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

XML как промежуточный формат обмена данными «оброс» экосистемой технологий и инструментов для работы с ним– специализированные редакторы, DOM-парсеры, XQUERY/XPATH, XSLT, специальные модули ETL и т. д. Все это многообразие и развитость инструментария идеологически приводят к тому, что у нас есть теперь технологии работы не просто с данными, а со специальными XML-данными. Это как отдельно «наука химия» и отдельно «наука химия для веществ, которые хранятся в синих коробках».

Описываемые далее принципы обработки позволили немножко «отмотать назад» условный прогресс технологий и перевести практически всю работу с XML данными на уровень «чистой» СУБД, без специфичного XML-инструментария. Такой подход дал возможность организовать унифицированное хранение любых XML-данных и обеспечить быстрый произвольный доступ к нужным частям информации. Кроме того, появилась возможность реализовывать ETL-функционал универсальным незатратным (практически без кодирования) способом.

Описываемый подход особенно хорошо показал себя на источниках данных большого объема и сложной структуры, с частыми изменениями схемы данных. Если вам приходится иметь дело с небольшим объемом информации, и/или структура несложная– возможно, данная технология вам (пока) не нужна.

Хорошим демо-кейсом для этой технологии могут служить открытые данные сервера госзакупок zakupki.gov.ru, доступные на соответствующем FTP: объём ежедневных обновлений – десятки и сотни тысяч XML файлов объемом в гигабайты или десятки гигабайт, в среднем раз в несколько недель выходит новая версия схемы данных.

Структура данных следует за требованиями законодательства, поэтому, например, информация об извещениях о проведении госзакупок представлена более чем десятком типов документов fcsNotification* в зависимости от типа закупки (электронный аукцион fcsNotificationEF, запрос котировок fcsNotificationZK, закупка у единственного поставщика fcsNotificationEP и т. п.)
Все эти документы основаны на одном базовом типе извещения но отличаются в деталях, поэтому для целей анализа все это многообразие при импорте надо в какой-то момент “схлопывать” и приводить к «единому знаменателю».

На данных госзакупок описываемый подход успешно применен и эффективно работает.

Кратко этапы/элементы описываемой технологии:

(1) Импорт всех XML данных в таблицу унифицированной структуры. Речь не идет о сохранении в базу документов целиком, мы импортируем данные поэлементно как пары “имя элемента” – “значение” или “имя атрибута” – “значение”. В результате данного этапа мы избавляемся от XML как формата хранения и получаем быстрый унифицированный доступ к данным всех импортированных XML-документов любой структуры (при этом нам больше не нужен XQUERY/XPATH).

(2) Вторым элементом технологии является создание спецификаций на “вытаскивание” нужных нам данных – выявление результирующих таблиц, в которые мы будем выливать данные, и маппинг полей источника и результата. Этот этап может быть проведен как на основе XSD-схем документов, так и без использования схем, через анализ закачанных на первом этапе образцов документов. Данный этап не требует никакого программирования и специальных навыков, основной инструментарий здесь – электронная таблица.

(3) Завершающие шаги – выборка нужной информации из первичного хранилища импорта (1) с помощью спецификаций (2), преобразование в “колоночное” представление (“пивотирование”) и автоматизированная трансформация в финальный “аналитический” формат – в терминах аналитических хранилищ данных это таблицы фактов структуры “звездочка” (star) со ссылками на справочники измерений (dimensions) и числовыми показателями-мерами (measures).

1. Первичный импорт.

Мы рассматриваем XML-документ как дерево, вершинами которого являются пары “имя”-“значение”. Таким образом, описываемый подход достаточно универсален и может быть применен к любому древовидному представлению данных.

Структура таблицы для загрузки данных из XML:

  • Record_ID: идентификатор элемента специального иерархического вида, позволяющий связывать друг с другом разные уровни документа
  • File_ID: поскольку в таблицу надо будет загружать содержимое множества XML-файлов, надо также хранить идентификатор файла
  • Path: полный путь к данному элементу начиная с корня документа (фактически, это XPATH-путь до данного элемента)
  • Element_Name: название элемента или атрибута
  • Element _Value: значение элемента или атрибута (в виде строки – так же, как оно хранится в XML)
  • Type: тип записи (элемент это или атрибут) – сохраним на всякий случай, вдруг потом надо будет из таблицы восстановить XML

Идея загрузки дерева в таблицу достаточно очевидная. В MS SQL (про другие СУБД не скажу, не смотрел) есть такая встроенная возможность –XML без указания схемы импортируется в так называемую EDGE-таблицу. Это не совсем то что нам нужно, т. к. в EDGE-формате хранятся отдельными записями имя элемента и его значение (то есть имя есть родительская запись для значения) – такой формат попросту неудобно использовать для дальнейших манипуляций. К тому же в EDGE таблице связи в дереве прописаны через указание ParentID.

Короче говоря, сделать нужное представление данных из EDGE таблицы можно, но придется немножко попотеть для “склеивания” названий и значений элементов, воссоздания XPATH до каждого элемента и создания иерархического идентификатора (о том, как мы его будем строить – чуть ниже). При большом объеме данных решение этих задач может оказаться довольно ресурсоемким, но зато можно обойтись единственным инструментом/языком.

Более правильный путь – получить дерево документа с помощью XML-парсера (какая-нибудь реализация есть практически в каждом языке и среде разработки) и заполнить нужную информацию одним проходом по документу.

Давайте посмотрим на конкретный пример. Есть у нас демо XML-файлы deliveries.xml и returns.xml. Файл deliveries.xml (доставки) содержит корневой элемент Deliveries, на верхнем уровне даты начала и окончания периода за который выгружены данные, дальше идут продукты с указанием названия и поставщика, по каждому продукту идет детализация информации доставок – дата, количество, цена.

Файл returns.xml (возвраты) абсолютно аналогичный, только корневой элемент называется Returns и в деталях элемент с датой по-другому называется.

Имена загруженных файлов хранятся в отдельной таблице, коды наших файлов там равны 2006 (deliveries) и 2007 (returns).

В нашей таблице-приемнике образ наших демо-документов будет выглядеть так:

Record_ID File_ID Path Element_Name Element_Value Type
001 2006 Deliveries E
001\001 2006 Deliveries\ PeriodBegin 2020-01-01 E
001\002 2006 Deliveries\ PeriodEnd 2020-01-31 E
001\003 2006 Deliveries\ Products E
001\003\001 2006 Deliveries\Products\ Product E
001\003\001\001 2006 Deliveries\Products\
Product\
Supplier Zaanse Snoepfabriek E
001\003\001\002 2006 Deliveries\Products\
Product\
ProductName Chocolade E
001\003\001\003 2006 Deliveries\Products\
Product\
Details E
001\003\001\003\
001
2006 Deliveries\Products\
Product\Details\
Detail E
001\003\001\003\
001\001
2006 Deliveries\Products\
Product\Details\Detail\
DeliveryDate 2020-01-03 E
001\003\001\003\
001\002
2006 Deliveries\Products\
Product\Details\Detail\
UnitPrice 10.2000 E
001\003\001\003\
001\003
2006 Deliveries\Products\
Product\Details\Detail\
Quantity 70 E

По поводу иерархического идентификатора Record_ID: его цель — уникально пронумеровать узлы дерева документа с сохранением информации о связях со всеми предками.

В приведенном примере мы используем простую платформенно-независимую реализацию c последовательной конкатенацией счетчиков элементов на каждом уровне дерева. Мы “добиваем” счетчик каждого уровня нулями до заданной фиксированной глубины, чтобы получить легкое и быстрое выделение идентификаторов предков любого уровня через выделение подстрок фиксированной длины.

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

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


Действительно, мы уже загрузили все наши данные в единое хранилище, не обращая внимания на возможную разницу в структуре документов, получили достаточно эффективный способ вычленять нужную информацию из всего массива простыми SQL-запросами, можем связывать между собой “вычлененные” подмножества данных.

Производительность такого решения как системы хранения исходников XML для разовых запросов, даже без оптимизации индексов и прочих ухищрений, будет явно гораздо выше, чем если бы вы хранили XML в файлах или даже записывали его в специальные поля БД. В нашем случае не надо запускать процедуру XPATH поиска (которая подразумевает новый парсинг) к каждому документу, мы это проделали один раз и дальше спокойно пользуемся сохраненным результатом через достаточно простые запросы.

На следующих этапах мы рассмотрим трансформацию этих XML документов в единую структуру данных, содержащую 3 таблицы: MovementReports (тип движения – доставка или возврат, даты начала и окончания из корня документа), Products (название и поставщик) и MovementDetails (цена, количество, дата – поле даты в результате будет единое для обоих исходных документов, несмотря на то, что в исходных файлах поля по-разному называются)

2. Создание спецификаций трансформации в результирующие таблицы.

Рассмотрим процесс создания спецификаций на маппинг исходных данных и результирующих таблиц. Для создания таких спецификаций нам потребуется еще кое-что.

2.1. Получение таблички со структурой документов.

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

Если у нас нет XSD-схемы или мы не хотим с ней связываться, то нам может быть достаточно загрузить в нашу таблицу какую-то репрезентативную выборку образцов XML-документов и построить с помощью группировки по полям Path и Element_Name нужный нам список.

Однако не забывайте, что мы хотим в итоге загрузить информацию в некие целевые “финальные” таблицы, поэтому нам надо знать где в XML хранятся отношения один-ко-многим. То есть надо понять какие элементы формируют “дочернюю” таблицу, где происходит размножение.

Иногда, если схема документа не очень сложная, нам это сразу понятно эмпирически, “глазками”. Также при группировке данных нашей “репрезентативной выборки” мы можем посчитать количество элементов и увидеть по этой статистике где они начинают “размножаться”. Но в общем случае, если у нас есть нормальная XSD-схема, лучше воспользоваться ей – размножение данных один ко многим мы “поймаем”, выявив XSD конструкцию maxoccurs=unbounded.

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

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

Во всех этих Oxygen, Altova, Liquid и менее навороченных нужная информация внутри, несомненно, используется – однако отдавать ее в нужном виде никто из них не умеет. Как правило, в продвинутом редакторе есть возможность генерировать Sample XML на основании схемы, но в XSD может быть конструкция choice, когда в документе может присутствовать что-то на выбор из нескольких разных элементов –тогда уж лучше реальные “боевые” образцы документов проанализировать. И еще — по образцу или образцам документов мы момент размножения информации один-ко-многим в явном виде тоже не поймаем.

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

Path Element_Name maxoccurs
Deliveries\ PeriodBegin
Deliveries\ PeriodEnd
Deliveries\Products\Product\ ProductName Products\Product
Deliveries\Products\Product\ Supplier Products\Product
Deliveries\Products\Product\Details\Detail\ DeliveryDate Products\Product\Details\Detail
Deliveries\Products\Product\Details\Detail\ Quantity Products\Product\Details\Detail
Deliveries\Products\Product\Details\Detail\ UnitPrice Products\Product\Details\Detail
Returns\ PeriodBegin
Returns\ PeriodEnd
Returns\Products\Product\ ProductName Products\Product
Returns\Products\Product\ Supplier Products\Product
Returns\Products\Product\Details\Detail\ Quantity Products\Product\Details\Detail
Returns\Products\Product\Details\Detail\ ReturnDate Products\Product\Details\Detail
Returns\Products\Product\Details\Detail\ UnitPrice Products\Product\Details\Detail

2.2. Описание трансформации

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

Path Element_
Name
maxoccurs Target
Table
Target
Field
Element
Depth
Additional
Info
Deliveries\ PeriodBegin MovementReports PeriodBegin_Date 1 Deliveries
Deliveries\ PeriodEnd MovementReports PeriodEnd_Date 1 Deliveries
Deliveries\. \Product\ ProductName …\Product Products ProductName_Dim 3
Deliveries\. \Product\ Supplier …\Product Products Supplier_Dim 3
Deliveries\. \. \. \Detail\ DeliveryDate …\Detail MovementDetails MovementDate_Date 5
Deliveries\. \. \. \Detail\ Quantity …\Detail MovementDetails Quantity_Val 5
Deliveries\. \. \. \Detail\ UnitPrice …\Detail MovementDetails UnitPrice_Val 5
Returns\ PeriodBegin MovementReports PeriodBegin_Date 1 Returns
Returns\ PeriodEnd MovementReports PeriodEnd_Date 1 Returns
Returns\. \Product\ ProductName …\Product Products ProductName_Dim 3
Returns\. \Product\ Supplier …\Product Products Supplier_Dim 3
Returns\. \. \. \Detail\ Quantity …\Detail MovementDetails MovementDate_Date 5
Returns\. \. \. \Detail\ ReturnDate …\Detail MovementDetails Quantity_Val 5
Returns\. \. \. \Detail\ UnitPrice …\Detail MovementDetails UnitPrice_Val 5

Вот какие поля мы добавили:

    Имя целевой таблицы TargetTable. Обратите внимание, что мы учитываем информацию о размножении один-ко-многим (столбец maxoccurs) для определения, в какую таблицу какие данные заливать.

Имя поля целевой таблицы TargetField. Мы далее используем подход сonvention over configuration и будем присваивать суффикс _Dim для полей, которые станут справочниками-измерениями (dimensions), суффикс _Date для полей дат и суффикс _Val для числовых полей- мер (measures). На следующих этапах процесса соответствующие утилиты по суффиксу поймут что делать с данным полем – строить и обновлять нужный справочник или преобразовывать значение в соответствующий формат.

Эффективная глубина вложенности элементов ElementDepth. Нам надо будет для последующих трансформаций сохранить единый код записи целевой таблицы на базе содержимого полей Record_ID и File_ID. В XML глубина элементов может быть разной, но попадать они должны будут в одну целевую таблицу, поэтому мы указываем, какую часть иерархического кода Record_ID нам надо сохранить, отбросив ненужный нам остаток. Благодаря фиксированной длине каждого сегмента иерархического кода, это будет достаточно “дешевая” операция выделения подстрок длины [Количество символов на сегмент кода]* ElementDepth.

  • Дополнительная информация AdditionalInfo. В результате нашей трансформации мы перегрузим исходные данные в разбивке по целевым таблицам в похожую структуру с новыми названиями полей, однако в некоторых местах нам надо будет сохранить важную информацию о том, из какого именно XPATH-пути мы брали исходные данные.
  • Эта техника открывает несколько интересных возможностей манипуляции трансформацией данных. Не углубляясь в детали, просто перечислим что мы можем сделать:

      Если у нас есть несколько исходных схем кодирования XML-данных (например, “старая” схема госзакупок по 95 ФЗ и “новая” по 44 ФЗ), мы можем на этапе описания трансформации привести их к единой структуре данных через унификацию названий полей.

    Можем, как упоминалось ранее, “схлопнуть” разные разделы в рамках одной или нескольких схем документов в единую, более компактную структуру хранения, как мы это делаем в нашем примере.

  • Можно также “схлопнуть” в единообразное представление данные разной глубины. Например, если брать схемы извещений о проведении госзакупок, то в разных схемах информация о лотах закупки может лежать “по адресу” \lot для однолотовых закупок (единственный элемент) и \lots\lot для многолотовых закупок (размножение). С помощью данного подхода можно достаточно просто весь этот зоопарк замаппить в единую таблицу информации о лотах.
  • После того, как наша табличка со спецификацией трансформации готова, мы загружаем ее в базу данных и джойним с нашим первичным хранилищем по полям Path и Element_Name.

    Конкатенацией File_ID, “обрезанного” в соответствии с ElementDepth значения поля Record_ID и значения AdditionalInfo формируем композитный ключ нашей целевой таблицы.

    Результат джойна выливаем для каждой целевой таблицы в отдельную “временную” таблицу (в зависимости от объема данных можно попробовать использовать результат запроса “ на лету ”), на следующем этапе с этими таблицами будут работать завершающие утилиты нашего “конвейера”.

    • До выливки мы имеем набор данных на уровне отдельных полей (элементов). Для того, чтобы соединить поля в записи результирующей таблицы, нам нужно иметь какой-то ключ, который будет однозначно идентифицировать запись целевой таблицы, в которую попадут соответствующие поля.
    • Иерархический идентификатор Record_ID может быть разной длины, в зависимости от “глубины залегания” отдельных элементов в схеме документа. Однако, если углубление уровня не сопровождается размножением элементов один-ко-многим, мы обрезаем наш Record_ID до минимальной достаточной глубины, определенной параметром ElementDepth, что обеспечит нам одинаковость идентификатора для всех полей нашей целевой таблицы. В наших демо-документах такой ситуации нет, но представьте, к примеру, что наш UnitPrice “разветвлялся” бы на 2 значения – оптовую и розничную цены UnitPrice\Retail и UnitPrice\Wholesale.

    • Поскольку в нашем базовом хранилище лежит содержимое множества файлов, в нашем ключе без значения File_ID не обойтись.
    • Следующие этапы преобразования данных работают только с полученными на данном шаге “трансформированными” таблицами, никакой сквозной системы настроек у нас нет. Тип поля (dimension/measure) мы передаем через суффиксы названий, но иногда нам надо передать “по цепочке” еще и информацию о том, в каком именно разделе документа мы брали информацию (помним, что мы можем трансформировать в одинаковый вид документы, закодированные разными схемами). Для передачи на следующий этап преобразования этой информации мы используем необязательный параметр нашей трансформации AdditionalInfo, “подцепив” его к нашему композитному ключу так, чтобы не нарушилась нужная нам идентификация целевых записей.

    Посмотрим, что получилось на выходе в нашем примере:

    MovementReports:

    KEY TargetField Element_Value
    001;2006@Deliveries PeriodBegin_Date 2020-01-01
    001;2006@Deliveries PeriodEnd_Date 2020-01-31
    001;2007@Returns PeriodBegin_Date 2020-02-01
    001;2007@Returns PeriodEnd_Date 2020-02-28

    Products:

    KEY TargetField Element_Value
    001\003\001;2006 Supplier_Dim Zaanse Snoepfabriek
    001\003\001;2006 ProductName_Dim Chocolade
    001\003\002;2006 Supplier_Dim Mayumis
    001\003\002;2006 ProductName_Dim Tofu
    001\003\001;2007 Supplier_Dim Pavlova, Ltd.
    001\003\001;2007 ProductName_Dim Pavlova
    001\003\002;2007 Supplier_Dim Formaggi Fortini s.r.l.
    001\003\002;2007 ProductName_Dim Mozzarella di Giovanni

    MovementDetails:

    KEY TargetField Element_Value
    001\003\001\003\001;2006 MovementDate_Date 2020-01-03
    001\003\001\003\001;2006 UnitPrice_Val 10.2000
    001\003\001\003\001;2006 Quantity_Val 70
    001\003\002\003\001;2006 MovementDate_Date 2020-01-09
    001\003\002\003\001;2006 UnitPrice_Val 18.6000
    001\003\002\003\001;2006 Quantity_Val 12
    001\003\002\003\002;2006 MovementDate_Date 2020-01-13
    001\003\002\003\002;2006 UnitPrice_Val 18.7000
    001\003\002\003\002;2006 Quantity_Val 20
    001\003\001\003\001;2007 MovementDate_Date 2020-02-21
    001\003\001\003\001;2007 UnitPrice_Val 13.9000
    001\003\001\003\001;2007 Quantity_Val 2
    001\003\002\003\001;2007 MovementDate_Date 2020-02-27
    001\003\002\003\001;2007 UnitPrice_Val 27.8000
    001\003\002\003\001;2007 Quantity_Val 4

    Обратите внимание – полученный ключ одинаков для всех полей, которые войдут в соответствующие записи наших целевых таблиц.

    3. Финальная обработка.

    3.1. Пивотирование

    Получив в результате предыдущей трансформации “заготовку” целевой таблицы с исходными данными, разбитыми на тройки — — , мы должны перевести ее в более привычный вид таблицы со множеством полей. Алгоритм этого преобразования очевиден – сначала группировкой значений нашего композитного ключа получаем “скелет” таблицы, потом осуществляем джойны этого “скелета” с таблицей-результатом трансформации по значению композитного ключа. (“Наращиваем мясо”, так сказать.)

    То есть получится N соединений “скелета” с подмножествами таблицы- результата трансформации, выделенными по именам полей, где N- количество названий полей в целевой таблице-результате трансформации.

    Мы благополучно “донесли” поле AdditionalInfo до данной стадии, закодировав его внутри композитного ключа. Теперь надо освободить наш ключ от этой “обузы” и отрезать AdditionalInfo-часть в новое поле AdditionalInfo_Dim.

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

    В итоге получатся такие вот

    MovementReports:

    Record_ID File_ID AdditionalInfo_Dim PeriodBegin_Date PeriodEnd_Date
    001 2006 Deliveries 2020-01-01 2020-01-31
    001 2007 Returns 2020-02-01 2020-02-28

    Products:

    Record_ID File_ID Supplier_Dim ProductName_Dim
    001\003\001 2006 Zaanse Snoepfabriek Chocolade
    001\003\002 2006 Mayumis Tofu
    001\003\001 2007 Pavlova, Ltd. Pavlova
    001\003\002 2007 Formaggi Fortini s.r.l. Mozzarella di Giovanni

    MovementDetails:

    Record_ID File_ID MovementDate_Date UnitPrice_Val Quantity_Val
    001\003\001\003\001 2006 2020-01-03 10.2000 70
    001\003\001\003\001 2007 2020-02-21 13.9000 2
    001\003\002\003\001 2006 2020-01-09 18.6000 12
    001\003\002\003\001 2007 2020-02-27 27.8000 4
    001\003\002\003\002 2006 2020-01-13 18.7000 20

    3.2. Нормализация

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

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

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

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

    В заключение описания процесса

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

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

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

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

    Можно прописать маппинг полей для «маленькой» трансформации данных – только для нужного нам пропущенного фрагмента. После того как мы “вытащим” недостающий кусок данных, мы сможем достаточно легко “подцепить” его к основному обработанному массиву через связку по иерархическому идентификатору.

    Выводы

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

    В процессе дальнейшей обработки ни одно животное не пострадало не возникло необходимости в создании или модификации каких-либо скриптов или объектов типа ETL task, специфичных для структуры исходных XML-файлов.

    Конечно, само программное окружение нашего “фреймворка” (инфраструктуру закачки и переливок данных) нужно было создать один раз, но затем интеграция данных любых структур XML сводится к редактированию таблицы маппинга исходного и целевого представлений.

    Продукты Vault

    Знания

    Изучите основы и оттачивайте навыки для повышения эффективности работы в Продукты Vault

    Не удалось извлечь оглавление

    Вложение файла в элемент

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

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

    Если в мастере элементов отображается столбец «Количество вложений», для каждого элемента с одним или несколькими вложения имеется значок скрепки. Для просмотра вложенных файлов щелкните значок скрепки при нажатой клавише CTRL.

    Управление вложениями файлов

      Правой кнопкой мыши щелкните элемент и выберите «Вложения».


    Отобразятся текущие вложения для элемента.

    Чтобы присоединить файлы, нажмите «Присоединить» и перейдите в расположение файла или нажмите «Найти», чтобы найти файлы в хранилище.

    Выберите один или несколько файлов и нажмите «Открыть».

    В диалоговом окне «Вложения» отобразится наиболее актуальная версия вложенного файла.

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

  • Выберите поле «Номер версии», а затем в раскрывающемся списке укажите версию файла, которую требуется закрепить.
  • Установите флажок «Закрепить» для закрепления файла в указанной версии.

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

  • Для удаления вложенного файла выберите требуемый файл и нажмите «Отсоединить».
  • Для сохранения изменений и выхода из диалогового окна нажмите кнопку «ОК».
  • jQuery: замена элемента, его вложение, перемещение и другие действия

    Как изменить содержимое элементов в jQuery

    В этом уроке мы попробуем свои силы в изменении содержимого элементов в jQuery.

    Итак, наиболее часто используемой операцией является изменение содержимого элементов. Вне библиотеки jQuery для этой цели используется свойство innerHTML объекта document. Например, чтобы вставить новый фрагмент в элемент с идентификатором divl, можно воспользоваться следующим кодом.

    Библиотека jQuery также позволяет использовать это свойство. Для этого находим элемент с помощью функции $ (), а затем преобразуем коллекцию элементов jQuery в набор DOM-элементов.

    Для этой цели можно также воспользоваться методом get () .

    В библиотеке jQuery для изменения содержимого элементов предназначены следующие методы.

    — text ( [3начение] ) — позволяет получить или задать текст элемента. Если параметр не указан, то метод возвращает текстовое значение без тегов. При наличии нескольких элементов в коллекции будут возвращены все значения в виде строки. Если необходимо получить значение только первого элемента из коллекции, то можно воспользоваться методом eq () .

    Можно также ограничить набор с помощью селектора :

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

    В этом примере строка в исходном HTML-коде будет выглядеть следующим образом.

    — html ( [3начение] ) — позволяет получить или задать HTML-код элемента. Если параметр не указан, то метод возвращает значение вместе с тегами. При наличии нескольких элементов в коллекции будет возвращено значение только первого элемента.

    При указании HTML-кода в качестве параметра он заменит содержимое всех элементов коллекции, и объектная модель документа будет обновлена. Выведем HTML-код во всех тегах div.

    Если необходимо изменить значение только первого элемента из коллекции, то можно воспользоваться методом eq () или селектором : first.

    — append (Выражение) — добавляет Выражение в конец содержимого выбранного элемента. В качестве параметра может быть указан HTML-код, DOM-элемент или коллекция элементов jQuery. Для примера добавим HTML-код в конец элемента.

    Результат будет выглядеть следующим образом.

    Теперь добавим DOM-элемент.

    — prepend(Выражение) — добавляет Выражение в начало содержимого выбранного элемента. В качестве параметра может быть указан HTML-код, DOM-элемент или коллекция элементов jQuery. Метод полностью идентичен методу appendO, за исключением того, что добавляет Выражение не в конец элемента, а в его начало. Для примера добавим HTML-код в начало элемента.

    — appendTo (Селектор) — добавляет коллекцию элементов jQuery в конец всех элементов, соответствующих указанному селектору. Для примера добавим HTML-код в конец элемента с идентификатором divl.

    Как видно из примера, мы поменяли параметры местами и использовали метод append () вместо метода appendTo ().

    — prependTo (Селектор) — добавляет коллекцию элементов jQuery в начало всех элементов, соответствующих указанному селектору. Для примера добавим HTML-код в начало элемента с идентификатором divl.

    Как добавить содержимое перед элементом или после него

    В предыдущем разделе мы рассмотрели изменение внутреннего содержимого элемента. Библиотека jQuery предоставляет также методы, которые позволяют добавить какое-либо содержимое перед элементом или после него. Рассмотрим эти методы.

    — aftег (Выражение) — добавляет Выражение после всех элементов коллекции. В качестве параметра может быть указан HTML-код, DOM-элемент или коллекция элементов jQuery. Для примера добавим HTML-код после элемента.


    А теперь добавим созданный элемент коллекции jQuery. $(«#divl»).after($(«Новый текст«));

    — before (Выражение) — добавляет Выражение перед всеми элементами коллекции. В качестве параметра может быть указан HTML-код, DOM-элемент или коллекция элементов jQuery. Метод полностью идентичен методу after (), за исключением того, что добавляет Выражение не после элемента, а перед ним. Для примера добавим HTML-код перед элементом.

    Результат будет выглядеть следующим образом.
    Новый текст

    — insertAfter (Селектор) — добавляет коллекцию элементов jQuery после всех элементов, соответствующих указанному селектору. Для примера добавим HTML-код после элемента с идентификатором divl.

    Результат будет таким же, как и при использовании метода after () .
    $(«#divl»).after(«Новый текст«);

    — insertBefore (Селектор) — добавляет коллекцию элементов jQuery перед всеми элементами, соответствующими указанному селектору. Для примера добавим HTML-код перед элементом с идентификатором divl.

    Результат будет таким же, как и при использовании метода before () .
    $(«#divl»).before(«Новый текст«);

    Вложение элементов

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

    — wraplnner (HTML-элемент или BОМ-элемент) —вкладывает внутреннее содержимое каждого элемента коллекции в другой элемент. Для примера выделим содержимое всех тегов div.

    Такого же эффекта можно достичь, передав в качестве параметра DOM-элемент.

    Можно также передать элемент, созданный с помощью функции $ ().

    — wrap (HTML-элемент или BОМ-элемент) —полностью вкладывает каждый элемент коллекции в другой элемент.

    Результат выполнения таков:

    — wrapAll (HTML-элемент или ВОМ-элемент) — собирает все элементы коллекции в одном месте и вкладывает их в другой элемент.

    Результат будет выглядеть следующим образом.
    Какой-то текст 1

    Как видно из примера, все элементы коллекции были размещены после первого элемента и расположены внутри тега u.

    Перемещение и клонирование элементов

    Если в качестве параметра методов before (), prepend (), append () и after () указать коллекцию существующих элементов jQuery, то они будут перемещены. Куда будут вставлены элементы, зависит от конкретного метода: before () (перед элементом), ргеpend() (в начало содержимого), append () (в конец содержимого), after () (после элемента). Для примера найдем все ссылки на странице и добавим их в конец элемента.

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

    Такого же эффекта можно достичь при помощи методов insertBefore (), prependTo (), appendTo () и insertAfter (). Куда будут вставлены элементы, зависит от конкретного метода: insertBefore О (перед элементом), prependTo () (в начало содержимого), appendTo () (в конец содержимого), insertAfter () (после элемента). Для примера найдем все ссылки на странице и добавим их перед элементом.

    В результате все ссылки будут размещены непосредственно перед элементом с идентификатором divl, и мы получим следующий HTML-код.

    Библиотека jQuery позволяет создавать копии существующих элементов (клонировать). Для этого предназначен метод clone ( [true] ). Если в качестве параметра указано значение true, то будут также клонированы и обработчики событий. Создадим копию первой ссылки в документе, а затем выведем ее после элемента с идентификатором divl. $(«а»).eq(0).clone().insertAfter(«#divl»);

    Результат будет выглядеть следующим образом.

    Очистка содержимого и удаление элемента

    Для очистки содержимого и удаления элемента применяются следующие методы.

    — empty () — удаляет все подэлементы текущего элемента.

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

    — remove ( [Селектор] ) — полностью удаляет элементы из объектной модели документа.

    Данный пример демонстрирует отсутствие элемента после щелчка на кнопке Удалить. Щелкнув на кнопке Количество элементов в первый раз, мы получим число 1, а если щелкнуть на ней после удаления элемента, то получим число 0.

    Если коллекция состоит более, чем из одного элемента, то будут удалены все элементы. Метод remove () позволяет задать дополнительное условие, которому должны соответствовать удаляемые элементы. В качестве примера удалим все ссылки с расширением . php.

    Изменение содержимого элементов

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

    Наиболее часто используемой операцией является изменение содержимого элементов. Вне библиотеки jQuery для этой цели используется свойство innerHTML объекта document. Например, чтобы вставить новый фрагмент в элемент с идентификатором divl, можно воспользоваться следующим кодом.

    Библиотека jQuery также позволяет использовать это свойство. Для этого находим элемент с помощью функции $ (), а затем преобразуем коллекцию элементов jQuery в набор DOM-элементов.

    Для этой цели можно также воспользоваться методом get () .

    В библиотеке jQuery для изменения содержимого элементов предназначены следующие методы.

    — text ( [3начение] ) — позволяет получить или задать текст элемента. Если параметр не указан, то метод возвращает текстовое значение без тегов. При наличии нескольких элементов в коллекции будут возвращены все значения в виде строки. Если необходимо получить значение только первого элемента из коллекции, то можно воспользоваться методом eq () .

    Можно также ограничить набор с помощью селектора :

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


    В этом примере строка в исходном HTML-коде будет выглядеть следующим образом.

    — html ( [3начение] ) — позволяет получить или задать HTML-код элемента. Если параметр не указан, то метод возвращает значение вместе с тегами. При наличии нескольких элементов в коллекции будет возвращено значение только первого элемента.

    При указании HTML-кода в качестве параметра он заменит содержимое всех элементов коллекции, и объектная модель документа будет обновлена. Выведем HTML-код во всех тегах div.

    Если необходимо изменить значение только первого элемента из коллекции, то можно воспользоваться методом eq () или селектором : first.

    — append (Выражение) — добавляет Выражение в конец содержимого выбранного элемента. В качестве параметра может быть указан HTML-код, DOM-элемент или коллекция элементов jQuery. Для примера добавим HTML-код в конец элемента.

    Результат будет выглядеть следующим образом.

    Теперь добавим DOM-элемент.

    — prepend(Выражение) — добавляет Выражение в начало содержимого выбранного элемента. В качестве параметра может быть указан HTML-код, DOM-элемент или коллекция элементов jQuery. Метод полностью идентичен методу append (), за исключением того, что добавляет Выражение не в конец элемента, а в его начало. Для примера добавим HTML-код в начало элемента.

    Результат будет выглядеть следующим образом.

    — appendTo (Селектор) — добавляет коллекцию элементов jQuery в конец всех элементов, соответствующих указанному селектору. Для примера добавим HTML-код в конец элемента с идентификатором divl.

    Результат будет таким же, как и при использовании метода append () .
    $(«#divl»).append(«Новый текст«);

    Как видно из примера, мы поменяли параметры местами и использовали метод append () вместо метода appendTo ().

    — prependTo (Селектор) — добавляет коллекцию элементов jQuery в начало всех элементов, соответствующих указанному селектору. Для примера добавим HTML-код в начало элемента с идентификатором divl.

    Результат будет таким же, как и при использовании метода prepend () .
    $(«#divl»).prepend(«Новый текст«);

    Скрипт обертывания изображений в теги + исключение других классов + удаление некоторых атрибутов

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

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

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

    Пустой элемент имеет следующий вид:

    Непустые элементы имеют вид:

    XML-документ состоит из двух основных частей: пролога и корневого элемента, как показано на рисунке 2.1.

    Рис. 2.1

    Пролог

    В данном примере документа пролог состоит из трех строк:

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

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

    Третья строка пролога представляет собой комментарий. Добавление комментариев в XML-документ не обязательно, но позволяет сделать его более понятным. Комментарий начинается с символов . Между этими двумя группами символов вы можете поместить любой текст (за исключением ); XML-процессор проигнорирует его.

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

    • объявление типа документа, определяющее тип и структуру документа.
    • объявление типа документа должно следовать после XML-объявления;
    • одна или несколько инструкций по обработке, содержащих информацию о порядке проходов при обработке приложения XML-процессором.

    Корневой элемент

    Второй основной частью XML-документа является единый корневой элемент, который в свою очередь содержит дополнительные элементы.

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

    В рассматриваемом примере корневой элемент – INVENTORY. Его начальный тег – , конечный тег – , а содержимое – восемь вложенных элементов BOOK.

    Примечание. Текст в XML-документе представляет собой перемежающиеся символьные данные и данные, относящиеся к разметке. Разметка – это текст, ограниченный разделителями и описывающий структуру документа. А именно, начальный и конечный теги элемента, теги пустого элемента, объявления типа документа, инструкции по обработке, ограничители раздела CDATA, символьные ссылки, ссылки на примитивы (entity). Остальной текст представляет собой символьные данные – реальное информационное содержимое документа (в нашем примере это названия, фамилии авторов, цена и другая информация о книге).

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

    В свою очередь, каждый элемент BOOK содержит ряд вложенных элементов, как показано на рисунке 2.2.

    Рис. 2.2

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

    Каждый из элементов, вложенных в элемент BOOK, например, элемент TITLE, содержит только символьные данные, как показано на рисунке 2.3.

    Вложение элементов

    вложение — включение, вставка; вклад, инвестиция; рефинансирование, вкладывание, реинвестирование, инвестирование, приложение, капвложения. Ant. займ, заём Словарь русских синонимов. вложение см. вклад 1 Словарь синонимов русского языка. Практический… … Словарь синонимов

    ВЛОЖЕНИЕ — ВЛОЖЕНИЕ, вложить и пр. см. влагать и вкладывать. Толковый словарь Даля. В.И. Даль. 1863 1866 … Толковый словарь Даля

    ВЛОЖЕНИЕ — ВЛОЖЕНИЕ, вложения, ср. 1. Действие по гл. вложить. || То, что вложено (в пакет; канц.). Со вложением (надпись на конверте, в который кроме письма вложен еще какой нибудь предмет). 2. Деньги, капитал, вложенный в какое нибудь предприятие (фин.… … Толковый словарь Ушакова

    ВЛОЖЕНИЕ — ВЛОЖЕНИЕ, я, ср. 1. см. вложить. 2. Вложенная сумма денег; вложенный предмет. Вложения в промышленность. Бандероль с ценным вложением. Толковый словарь Ожегова. С.И. Ожегов, Н.Ю. Шведова. 1949 1992 … Толковый словарь Ожегова

    вложение — — [[Англо русский словарь сокращений транспортно экспедиторских и коммерческих терминов и выражений ФИАТА]] Тематики услуги транспортно экспедиторские EN encl.enclosure … Справочник технического переводчика

    Вложение — В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия

    Вложение — ср. 1. процесс действия по гл. вложить 1., 2. отт. Результат такого действия. 2. Ценные бумаги, документы, вложенные в почтовое отправление. 3. см. тж. вложения Толковый словарь Ефремовой. Т. Ф. Ефремова. 2000 … Современный толковый словарь русского языка Ефремовой

    вложение — вложение, вложения, вложения, вложений, вложению, вложениям, вложение, вложения, вложением, вложениями, вложении, вложениях (Источник: «Полная акцентуированная парадигма по А. А. Зализняку») … Формы слов

    вложение — влож ение, я … Русский орфографический словарь

    вложение — (2 с), Пр. о вложе/нии; мн. вложе/ния, Р. вложе/ний … Орфографический словарь русского языка

    Илон Маск рекомендует:  Что такое код msession_randstr
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL