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


Содержание

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

HTML страницы — это куча вложенных друг в друга элементов. Структура документа схожа с деревом. Некоторые элементы являются сестринскими — как две соседние ветки одного дерева. Некоторые элементы могут иметь «детей» — другие элементы. Это как маленькая ветка растет от более крупной. Элементы, которые не имеют детей, называются листовыми узлами (leaf node). Если посмотреть на это все в обратную сторону, то у детей есть свои «родители» (parent node). Родитель всех родителей — это корневой элемент (root element). В HTML корневым всегда является элемент .

Он может выглядеть так:

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

Первое — это атрибут xmlns. Он пришел из XHTML 1.0. Атрибут говорит, что элементы этой страницы находятся в пространстве имен XHTML (http://www.w3.org/1999/xhtml). Но элементы HTML5 всегда в этом пространстве, так что надобности в этом атрибуте больше нет. Страница будет отображена одинаково с этим атрибутом и без него.

В общем, можно смело выбрасывать xmlns:

Осталось два атрибута: lang и xml:lang. Оба определяют язык, использующийся на данной странице. En означает английский. Так зачем же целых два атрибута, обозначающих одно и тоже? Это снова пришло из XHTML. В HTML5 толку от xml:lang уже никакого.

Поэтому можно писать так:

Ну вот собственно и все, что я хотел сказать по этому поводу.

Создание корректно сформированных XML-документов. Структура XML-документа. Пролог, корневой элемент

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

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

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

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

Обратите внимание на то, как используются описанные нами в секции CDATAсущности. Если требуется вывести какой-нибудь спецсимвол, например, & или

Рис. 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.

Простота использования

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

Правильно построенные и действительные документы XML

Стандартом определены два уровня правильности документа XML:

· Правильно построенный (англ. well-formed). Правильно построенный документ соответствует всем общим правилам синтаксиса XML, применимым к любому XML-документу. И если, например, начальный тег не имеет соответствующего ему конечного тега, то это неправильно построенный документ XML. Документ, который неправильно построен, не может считаться документом XML; XML-процессор (парсер) не должен обрабатывать его обычным образом и обязан классифицировать ситуацию как фатальная ошибка.

· Действительный (англ. valid). Действительный документ дополнительно соответствует некоторым семантическим правилам. Это более строгая дополнительная проверка корректности документа на соответствие заранее определённым, но уже внешним правилам, в целях минимизации количества ошибок, например, структуры и состава данного, конкретного документа или семейства документов. Эти правила могут быть разработаны как самим пользователем, так и сторонними разработчиками, например, разработчиками словарей или стандартов обмена данными. Обычно такие правила хранятся в специальных файлах — схемах, где самым подробным образом описана структура документа, все допустимые названия элементов, атрибутов и многое другое. И если документ, например, содержит не определённое заранее в схемах название элемента, то XML-документ считается недействительным; проверяющий XML-процессор (валидатор) при проверке на соответствие правилам и схемам обязан (по выбору пользователя) сообщить об ошибке.

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

Синтаксис XML

В этом разделе рассматривается лишь правильное построение документов XML, то есть их синтаксис.

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

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

Важнейшее обязательное синтаксическое требование заключается в том, что документ имеет только один корневой элемент(англ. root element) (также иногда называемый элемент документа (англ. document element)). Это означает, что текст или другие данные всего документа должны быть расположены между единственным начальным корневым тегом и соответствующим ему конечным тегом.

Комментарий

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

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

Содержимым элемента (англ. content) называется всё, что расположено между открывающим и закрывающим тегами, включая текст и другие (вложенные) элементы. Ниже приведён пример XML-элемента, который содержит открывающий тег, закрывающий тег и содержимое элемента:

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

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

Годом рождения XML можно считать 1996 год, в конце которого появился черновой вариант спецификации языка, или 1998 год, когда эта спецификация была утверждена. А началось всё с появления в 1986 году языка SGML.

SGML (англ. Standard Generalized Markup Language — стандартный обобщённый язык разметки) заявил о себе как гибкий, комплексный и всеохватывающий мета-язык для создания языков разметки. Несмотря на то, что понятие гипертекста появилось в 1965 году, SGML не имеет гипертекстовой модели. Создание SGML можно с уверенностью назвать попыткой объять необъятное, так как он объединяет в себе такие возможности, которые крайне редко используются все вместе. В этом и состоит его главный недостаток — сложность и, как следствие, дороговизна этого языка ограничивает его использование только крупными компаниями, которые могут позволить себе купить соответствующее программное обеспечение и нанять высокооплачиваемых специалистов. Кроме того, у небольших компаний редко возникают настолько сложные задачи, чтобы привлекать к их решению SGML.

Наиболее широко SGML применяется для создания других языков разметки, именно с его помощью был создан язык разметки гипертекстовых документов — HTML, спецификация которого была утверждена в 1992 году. Его появление было связано с необходимостью организации стремительно увеличивающегося массива документов в сети Интернет. Бурный рост количества подключений к Интернету и, соответственно, веб-серверов повлек за собой такую потребность в кодировке электронных документов, с которой не мог справиться SGML вследствие высокой трудности освоения. Появление HTML — очень простого языка разметки — быстро решило эту проблему: лёгкость в изучении и богатство средств оформления документов сделали его самым популярным языком для пользователей Интернет. Но, по мере роста количества и изменения качества документов в Сети, росли и предъявляемые к ним требования, и простота HTML превратилась в его главный недостаток. Ограниченность количества тегов и полное безразличие к структуре документа побудили разработчиков в лице консорциума W3C к созданию такого языка разметки, который был бы не столь сложен, как SGML, и не настолько примитивен, как HTML. В результате на свет появился язык XML, сочетающий в себе простоту HTML, логику разметки SGML и удовлетворяющий требованиям Интернета.

Правильно построенные и действительные документы XML

Стандартом определены два уровня правильности документа XML:

  • Правильно построенный (англ.well-formed ). Правильно построенный документ соответствует всем общим правилам синтаксиса XML, применимым к любому XML-документу. И если, например, начальный тег не имеет соответствующего ему конечного тега, то это неправильно построенный документ XML. Документ, который неправильно построен, не может считаться документом XML; XML-процессор (парсер) не должен обрабатывать его обычным образом и обязан классифицировать ситуацию как фатальная ошибка.
  • Действительный (англ.valid ). Действительный документ дополнительно соответствует некоторым семантическим правилам. Это более строгая дополнительная проверка корректности документа на соответствие заранее определённым, но уже внешним правилам, в целях минимизации количества ошибок, например, структуры и состава данного, конкретного документа или семейства документов. Эти правила могут быть разработаны как самим пользователем, так и сторонними разработчиками, например, разработчиками словарей или стандартов обмена данными. Обычно такие правила хранятся в специальных файлах — схемах, где самым подробным образом описана структура документа, все допустимые названия элементов, атрибутов и многое другое. И если документ, например, содержит не определённое заранее в схемах название элемента, то XML-документ считается недействительным; проверяющий XML-процессор (валидатор) при проверке на соответствие правилам и схемам обязан (по выбору пользователя) сообщить об ошибке.

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

Синтаксис XML

В этом разделе рассматривается лишь правильное построение документов XML, то есть их синтаксис.

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

Рассмотрим пример простого кулинарного рецепта, размеченного с помощью XML:


Объявление XML

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

Спецификация требует, чтобы процессоры XML обязательно поддерживали Юникод-кодировки UTF-8 и UTF-16 (UTF-32 не обязателен). Признаются допустимыми, поддерживаются и широко используются (но не обязательны) другие кодировки, основанные на стандарте ISO/IEC 8859, также допустимы другие кодировки, например, русские Windows-1251, KOI-8. Часто в тегах принципиально не используют не-латинские буквы, в этом случае UTF-8 является очень удобной кодировкой — объём, как правило, меньше, чем при UTF-16; декодирование может быть выполнено как для всего документа, так и для конкретных атрибутов и текстов; весь документ не содержит запрещённых символов при попытке разбора с неправильной кодировкой.

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

Важнейшее обязательное синтаксическое требование заключается в том, что документ имеет только один корневой элемент (англ. root element ) (также иногда называемый элемент документа (англ. document element )). Это означает, что текст или другие данные всего документа должны быть расположены между единственным начальным корневым тегом и соответствующим ему конечным тегом.

Следующий простейший пример — правильно построенный документ XML:

Следующий пример не является корректным XML-документом, потому что имеет два корневых элемента:

Комментарий

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

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

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

Илон Маск рекомендует:  Как очистить экран в консоли win32

Содержимым элемента (англ. content ) называется всё, что расположено между открывающим и закрывающим тегами, включая текст и другие (вложенные) элементы. Ниже приведён пример XML-элемента, который содержит открывающий тег, закрывающий тег и содержимое элемента:

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

В приведённом примере у элемента « ingredient » есть два атрибута: « amount », имеющий значение «3», и « unit », имеющий значение «стакан». С точки зрения XML-разметки, приведённые атрибуты не несут никакого смысла, а являются просто набором символов.

Кроме текста, элемент может содержать другие элементы:

В данном случае элемент « instructions » содержит три элемента « step ».

XML не допускает перекрывающихся элементов. Например, приведённый ниже фрагмент некорректен, так как элементы « em » и « strong » перекрываются.

Для обозначения элемента без содержания, называемого пустым элементом, необходимо применять особую форму записи, состоящую из одного тега, в котором после имени элемента ставится косая черта. Если в DTD элемент не объявлен пустым, но в документе он не имеет содержания, для него допускается применять следующие (три) формы записи. Например:

Спецсимволы

В XML определены два метода записи специальных символов: ссылка на сущность и ссылка по номеру символа.

Сущностью (англ. entity ) в XML называются именованные данные, обычно текстовые, в частности, спецсимволы. Ссылка на сущность (англ. entity references ) указывается в том месте, где должна быть сущность и состоит из амперсанда ( & ), имени сущности и точки с запятой ( ; ).

В XML есть несколько предопределённых сущностей, таких как lt (ссылаться на неё можно написав < ) для левой угловой скобки и amp (ссылка — & ) для амперсанда. Возможно также определять собственные сущности. Помимо записи с помощью сущностей отдельных символов, их можно использовать для записи часто встречающихся текстовых блоков.

Ниже приведён пример использования предопределённой сущности для избежания использования знака амперсанда в названии:

Полный список предопределённых сущностей состоит из & ( & ), < ( ), > ( > ), ' ( ‘ ) и " ( » ) — последние две полезны для записи разделителей внутри значений атрибутов. Определить свои сущности можно в DTD-документе.

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

Ссылка по номеру символа (англ. numeric character reference ) выглядит как ссылка на сущность, но вместо имени сущности указывается символ # и число (в десятичной или шестнадцатеричной записи), являющееся номером символа в кодовой таблице Юникод. Это обычно символы, которые невозможно закодировать напрямую, например, буква арабского алфавита в ASCII-кодированном документе. Амперсанд может быть представлен следующим образом:

Существуют и другие правила, касающиеся составления корректного XML-документа.

Сильные и слабые стороны

Достоинства

  • XML — язык разметки, позволяющий стандартизировать вид файлов-данных, используемых компьютерными программами, в виде текста, понятного человеку;
  • XML поддерживает Юникод;
  • в формате XML могут быть описаны такие структуры данных, как записи, списки, деревья, форматированный текст;
  • XML — это самодокументируемый формат, который описывает структуру и имена полей так же как и значения полей;
  • XML имеет строго определённый синтаксис и требования к анализу, что позволяет ему оставаться простым, эффективным и непротиворечивым. Одновременно с этим, разные разработчики не ограничены в выборе экспрессивных методов (например, можно моделировать данные, помещая значения в параметры тегов или в тело тегов, можно использовать различные языки и нотации для именования тегов и т. д.);
  • XML — формат, основанный на международных стандартах;
  • Иерархическая структура XML подходит для описания практически любых типов документов, кроме аудио и видео мультимедийных потоков, растровых изображений, сетевых структур данных и двоичных данных;
  • XML представляет собой простой текст, свободный от лицензирования и каких-либо ограничений;
  • XML не зависит от платформы;
  • XML является подмножеством SGML (который используется с 1986 года). Уже накоплен большой опыт работы с языком и созданы специализированные приложения;
  • XML не накладывает требований на порядок расположения атрибутов в элементе и вложенных элементов разных типов [6] , что существенно облегчает выполнение требований обратной совместимости;
  • В отличие от бинарных форматов, XML содержит метаданные об именах, типах и классах описываемых объектов, по которым приложение может обработать документ неизвестной структуры (например, для динамического построения интерфейсов [7] );
  • XML имеет реализации парсеров для всех современных языков программирования; [8]
  • Существует стандартный механизм преобразования XSLT, реализации которого встроены в браузеры, операционные системы, веб-серверы.
  • XML поддерживается на низком аппаратном, микропрограммном и программном уровнях в современных аппаратных решениях. [9]

Недостатки

  • Синтаксис XML избыточен. [10]
  • Размер XML-документа существенно больше бинарного представления тех же данных. В грубых оценках величину этого фактора принимают за 1 порядок (в 10 раз).
  • Размер XML-документа существенно больше, чем документа в альтернативных текстовых форматах передачи данных (например, JSON[6] , YAML, Protocol Buffers) и особенно в форматах данных, оптимизированных для конкретного случая использования.
  • Избыточность XML может повлиять на эффективность приложения. Возрастает стоимость хранения, обработки и передачи данных.
  • XML содержит метаданные (об именах полей, классов, вложенности структур), и одновременно XML позиционируется как язык взаимодействия открытых систем. При передаче между системами большого количества объектов одного типа (одной структуры), передавать метаданные повторно нет смысла, хотя они содержатся в каждом экземпляре XML описания.
  • Для большого количества задач не нужна вся мощь синтаксиса XML и можно использовать значительно более простые и производительные решения. [11]
  • Неоднозначность моделирования.
  • Нет общепринятой методологии для моделирования данных в XML, в то время как для реляционной модели и объектно-ориентированной такие средства разработаны и базируются на реляционной алгебре, системном подходе и системном анализе.
  • В природе есть множество объектов и явлений, для описания которых разные структуры данных (сетевая, реляционная, иерархическая) являются естественными, и отображение объекта в неестественную для него модель является болезненным для его сути. В случае с реляционной и иерархической моделями определены процедуры декомпозиции, обеспечивающие относительную однозначность, чего нельзя сказать о сетевой модели. [12]

  • В результате большой гибкости языка и отсутствия строгих ограничений, одна и та же структура может быть представлена множеством способов (различными разработчиками), например, значение может быть записано как атрибут тега или как тело тега и т. д. Например:
    • 1 1
    • и т. д. [13]
  • Поддержка многих языков в именовании тегов дает возможность назвать, например вес русским словом, в таком случае компьютер никак не сможет установить соответствия этого поля с полем weight в англоязычной версии программы и с полями в версиях модели объекта на множестве других языков.
  • XML не содержит встроенной в язык поддержки типов данных. В нём нет строгой типизации, то есть понятий «целых чисел», «строк», «дат», «булевых значений» и т. д.
  • Иерархическая модель данных, предлагаемая XML, ограничена по сравнению с реляционной моделью и объектно-ориентированными графами и сетевой моделью данных.
  • Выражение неиерархических данных (например графов) требует дополнительных усилий
  • Кристофер Дейт, специалист в области реляционных баз данных, автор классического учебника «An Introduction to Database Systems», отмечал, что «…XML является попыткой заново изобрести иерархические базы данных…» [14] .
  • Пространства имён XML сложно использовать и их сложно реализовывать в XML-парсерах.
  • Существуют другие, обладающие сходными с XML возможностями, текстовые форматы данных, которые обладают более высоким удобством чтения человеком (YAML, JSON, SweetXML [15] , XF [16] ).

Отображение XML во Всемирной паутине

Наиболее распространены три способа преобразования XML-документа в отображаемый пользователю вид:

  1. Применение стилей CSS;
  2. Применение XSL;
  3. Написание на каком-либо языке программирования обработчика XML-документа.

Без использования CSS или XSL XML-документ отображается как простой текст в большинстве веб-браузеров. Некоторые браузеры, такие как Internet Explorer, Mozilla Firefox и Opera (встроенный инструмент Opera Dragonfly) отображают структуру документа в виде дерева, позволяя сворачивать и разворачивать узлы с помощью нажатий клавиши мыши.

Применение стилей CSS

Процесс аналогичен применению CSS к HTML-документу для отображения.

Для применения CSS при отображении в браузере, XML-документ должен содержать специальную ссылку на таблицу стилей. Например:

Это отличается от подхода HTML, где используется элемент
.

Применение XSL

XSL является семейством рекомендаций, описывающих языки преобразования и визуализации XML-документов. Документ трансформируется в формат, подходящий для отображения в браузере. Браузер — это наиболее частое использование XSL, но не стоит забывать, что с помощью XSL можно трансформировать XML в любой формат, например VRML, PDF, текст.

Для задания XSL трансформации (XSLT) на стороне клиента требуется наличие в XML инструкции следующего вида:

Словари XML

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

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

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

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

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

Версии XML

  • XML 1.0
  • XML 1.1

См. также

Примечания

  1. XML Media Types, RFC 3023 9–11. IETF (январь 2001). Архивировано из первоисточника 22 августа 2011.Проверено 4 января 2010.
  2. XML Media Types, RFC 3023 7–9. IETF (январь 2001). Архивировано из первоисточника 22 августа 2011.Проверено 4 января 2010.
  3. M. Murata, D. Kohn, and C. LilleyInternet Drafts: XML Media Types. IETF (24 сентября 2009). Архивировано из первоисточника 22 августа 2011.Проверено 10 июня 2010.
  4. Extensible Markup Language (XML) 1.0 (Fifth Edition)
  5. Extensible Markup Language (XML) 1.1 (Second Edition)
  6. 12JSON: The Fat-Free Alternative to XML
  7. XML.com: Very Dynamic Web Interfaces
  8. XML Parsers
  9. Intel XML Accelerator
  10. David Megginson. Imperfect XML: Rants, Raves, Tips, and Tricks … from an Insider. Chapter 8
  11. Data File Metaformats
  12. Gustavo Alonso. Myths around Web Services Swiss Federal Institute of Technology, page 6
  13. Tim Bray. Using XML in Internet Protocols Sun Microsystems
  14. O’Reilly Network: An Interview with Chris Date
  15. SweetXML
  16. XFHome.org — формат обмена данными XF

Литература

  • Дэвид Хантер, Джефф Рафтер, Джо Фаусетт, Эрик ван дер Влист, и др. XML. Работа с XML, 4-е издание = Beginning XML, 4th Edition. — М .: «Диалектика», 2009. — 1344 с. — ISBN 978-5-8459-1533-7
  • Дэвид Хантер, Джефф Рафтер и др. XML. Базовый курс = Beginning XML. — М .: Вильямс, 2009. — 1344 с. — ISBN 978-5-8459-1533-7

  • Роберт Тейбор. Реализация XML Web-служб на платформе Microsoft .NET = Microsoft .NET XML Web Services. — М .: Вильямс, 2002. — 464 с. — ISBN 0-672-32088-6

Ссылки

  • XML на сайте Консорциума Всемирной паутины (W3C)
  • Официальная спецификация стандарта XML 1.0 (англ.)
  • Официальная спецификация стандарта XML 1.1 (англ.)
  • Doug T >
    Стандарты Консорциума Всемирной паутины Рекомендации

    Canonical XML • CDF • CSS • DOM • Geolocation API • HTML • ITS • MathML • OWL • P3P • PLS • RDF (Schema) • SISR • SKOS • SMIL • SOAP • SRGS • SSML • SVG • SPARQL • Timed Text • VoiceXML • WSDL • XForms • XHTML • XHTML+RDFa • XInclude • XLink • XML (Base • Encryption • Events • Information Set • namespace • Schema • Signature) • XPath / 1.0 / 2.0 • XPointer • XProc • XQuery • XSL • XSL-FO • XSLT (элементы) • XUP

    Примечания Рабочие проекты

    CCXML • CURIE • HTML5 • InkML • RIF • SCXML • SMIL Timesheets • sXBL • WICD • XFDL • XFrames • XBL • XHTML+MathML+SVG • XMLHttpRequest

    Guidelines

    Web Content Accessibility Guidelines

    Initiative

    Multimodal Interaction Activity • Markup Validation Service • Web Accessibility Initiative

    Deprecated Организации

    World Wide Web Foundation • SVG Working Group • WebOnt • Device Description Working Group • WHATWG

    Agora • Argo • Arena • Amaya • CERN httpd • Libwww • Line Mode Browser

    Интеграция 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 сводится к редактированию таблицы маппинга исходного и целевого представлений.

    Язык XML практика и теория

    Данный раздел посвящен работе с XML. В нём будет собран, как теоретический, так и практический материал. Будут рассмотрены основные операции с XML файлами, а так же взаимодействие с LINQ и многое другое.

    Создание XML файла

    XML (Extensible Markup Language) — расширяемый язык разметки, применяется для создания баз данных, web страниц, используется для обмена информацией между программами, применяется в таких технологиях, как Ajax, SOAP, а так же является основой языка XAML, с которым Вы можете встретиться при работе с WPF.

    Для создания xml файла нам всего лишь необходимо внести

    Структура XML файла

    Любой XML файл, начинается с объявления декларации.

    Декларация

    Декларация xml файла включает в себя:

    Версию (version) — номер версии языка XML, 1.0 и 1.1

    Если Вы используете xml version 1.0, то строку декларации можно не указывать, если Вы используете версию 1.1, то необходимо обязательно указать данную строку.

    Кодировку (encoding) — указывает кодировку файла

    Данной записью Вы не устанавливаете кодировку физическому файлу! А только лишь даёте понять программе, которая будет обрабатывать данный файл, в какой кодировке, содержаться данные внутри файла. При этом Вы должны гарантировать, что кодировка документа и кодировка, указанная в строке декларации совпадают.

    Чтобы установить кодировку документу, Вы можете воспользоваться, к примеру, программой Notepad++

    Элементы xml файла

    Язык XML состоит из элементов.

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

    В одном файле может содержаться любое количество элементов.

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

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

    Теги бывают: парные и одиночные.

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

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

    XML регистро-зависимый язык

    Комментарии

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

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

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

    Первым всегда указывается корневой элемент (root element), в одном XML документе может быть только один корневой элемент!

    В данном примере, создано два корневых элемента

      не правильно

        правильно

      Во втором примере создан один корневой элемент «Root», который содержит обычный элемент «Admin».

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

      «library» корневой элемент содержащий элемент book, который содержит вложенные элементы: title, author, year.

      Атрибуты xml файла

      Атрибуты устанавливают в открывающем теге любого элемента.

      Синтаксис: имя = «значение», заключенное в двойные кавычки.

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

      Ошибка, присутствуют два повторяющихся атрибута «id», а так же между id и number содержится пробел.

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

      XSL: понятие, корневой элемент xsl:stylesheet и элементы верхнего уровня

      XSLT (eXtensible Stylesheet Language Transformations) — язык преобразования XML-документов. XSLT-инструкции оформляются в виде отдельного xslt-файла, который затем используется XSLT-процессором для трансформации xml-документа — исходного дерева в конечное дерево. Конечным деревом может быть другой xml-документ, html-документ или просто текст. В результате XSLT-преобразования конечный документ может иметь совсем другую структуру.

      Сам по себе XSL-файл является правильным xml-документом. Поэтому он должен соответствовать всем требования, предъявляемым к xml-документам. Во-первых, как и все xml-документы, он должен начинаться со строки:

      • version – указание на версию xml (обычно 1.0 ),
      • encoding – кодировка документа, например, utf-8 .

      Стиль ( xsl:stylesheet )

      Корневым элементом для XSL-документа является элемент xsl:stylesheet или его устаревший аналог xsl:transform , внутри которого и содержится все описание стиля (правил трансформации), т.е. все остальные элементы — инструкции и шаблоны.

      Синтаксис:

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

      Атрибуты:

      • version – обязательный атрибут, указывает версию XSL, как правило это 1.0
      • xmlns:xsl – обязательный атрибут, ссылка на URI пространства имен, как правило это http://www.w3.org/1999/XSL/Transform
      • id — необязательный атрибут, может содержать уникальный идентификатор. Этот атрибут используется, когда элемент xsl:stylesheet содержится не в отдельном документе, а является частью исходного документа. В этом случае атрибут позволяет идентифицировать стиль внутри исходного документа
      • extension-element-prefixes — необязательный атрибут, содержит перечень префиксов пространств имен расширений, используемых в преобразовании. Расширения должны поддерживаться XSLT-процессором
      • exclude-result-prefixes — необязательный атрибут, содержит перечень префиксов пространств имен, которые следует исключать из конечного документа

      Элементы верхнего уровня

      Непосредственные потомки (children) элемента xsl:stylesheet называются элементами верхнего уровня. К ним в частности относятся:

      • xsl:import
      • xsl:include
      • xsl:strip-space
      • xsl:preserve-space
      • xsl:output
      • xsl:key
      • xsl:decimal-format
      • xsl:namespace-alias
      • xsl:attribute-set
      • xsl:variable
      • xsl:param
      • xsl:template

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

      Особенности XHTML 1.1

      Статья основана на оригинальном документе W3C — XHTML™ 1.1 — Module-based XHTML — Second Edition: W3C Working Draft 16 February 2007. Он может быть изменен, но скорее всего станет заменой для существующей рекомендации — XHTML™ 1.1 — Module-based XHTML.

      Строгое соответствие документов

      Документы, полностью совместимые с XHTML 1.1 — должны соответствовать следующим критериям:

      1. Корневым элементом документа должен быть элемент .
      2. Корневой элемент документа ( ) должен указывать на пространство имен XHTML с помощью атрибута xmlns . Указателем пространства имен для XHTML является «http://www.w3.org/1999/xhtml», то есть открывающим тегом html должна быть конструкция вида: .
      3. Корневой элемент может также содержать атрибут schemaLocation . Атрибут schemaLocation для XHTML определен в виде: «http://www.w3.org/MarkUp/SCHEMA/xhtml11.xsd» .
      4. Должно присутствовать объявление типа документа DOCTYPE , предшествующее корневому элементу. Идентификатор, включенный в объявление DOCTYPE , должен указывать на соответствующий DTD. Этот идентификатор может выглядеть следующим образом:

      Приведем пример документа, соответствующего XHTML 1.1:

      Отметим, что в этом примере, включено объявление XML. Объявление XML, подобное вышеуказанному требуется не во всех XML документах. Авторам XHTML документов крайне рекомендуется использовать объявление XML во всех своих документах. Такое объявление требуется, когда кодировка XML-документа отличается от UTF-8 или UTF-16.

      У документов XHTML 1.1 следует указывать тип содержимого документа — либо как text/html , либо application/xhtml+xml .

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

      Тип документов XHTML 1.1

      XHTML 1.1 — это полнофункциональный тип документов с развитой семантикой. Однако, он не так разнообразен в функциональном отношении как типы XHTML 1.0 Transitional или XHTML 1.0 Frameset. Начиная с версии XHTML 1.1, тип документа не содержит устаревших элементов, содержащихся в типах XHTML 1.0 или HTML 4. Несмотря на эти исключения, или возможно благодаря им, тип XHTML 1.1 является надежной базой для создания новых типов документов в будущем с полной поддержкой различными агентами пользователей.

      Тип XHTML 1.1 составлен из следующих XHTML модулей.

      Структурный модуль body, head, html, title Модуль для работы с текстом abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p, pre, q, samp, span, strong, var Гипертекстовый модуль a Модуль списков dl, dt, dd, ol, ul, li Модуль объектов object, param Модуль различных способов представления b, big, hr, i, small, sub, sup, tt Модуль редактирования del, ins Модуль поддержки двунаправленного текста bdo Модуль форм button, fieldset, form, input, label, legend, select, optgroup, option, textarea Табличный модуль caption, col, colgroup, table, tbody, td, tfoot, th, thead, tr Модуль изображений img Модуль карт изображений клиентской стороны area, map Модуль карт изображений стороны сервера Атрибут ismap, включенный в img Модуль внутренних событий Атрибуты событий Модуль метаинформации meta Модуль сценариев noscript, script Модуль таблиц стилей style Модуль атрибутов стилей (Устаревший) Атрибут style Модуль ссылок link Модуль базы base

      XHTML также использует модуль Ruby Annotation:

      Модуль Ruby Annotation ruby, rbc, rtc, rb, rt, rp

      Названия модулей в списке приведены согласно своим определениям в текущей версии «XHTML Modularization». Более подробная информация о модулях содержится в документе «XHTML Modularization».

      Отличия от XHTML 1.0 Strict

      XHTML 1.1 отличается от обеих технологий HTML 4 и XHTML 1.0. Наиболее значимым является устранение устаревших элементов. Вообще, существует стратегия определять язык разметки со структурно-функциональной стороны, вне зависимости от таблиц стилей, применяемых для дизайна документов.

      Отличия могут быть сформулированы следующим образом:

      1. Атрибут lang заменен атрибутом xml:lang .
      2. В элементах a и map , атрибут name заменен атрибутом id .
      3. Коллекция элементов « Ruby » расширена.

      Таким образом, тип XHTML 1.1 несильно отличается от XHTML 1.0 Strict, однако, эти отличия достаточно существенны и их необходимо учитывать.

      Синтаксис и основные понятия языка 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-документа:

      Шаг 2. Корневой элемент html.

      После элемента doctype, который мы рассмотрели в предыдущей заметке, идет элемент .

      Этот элемент присутствует на всех html-страницах, которые вы будете просматривать в браузере.

      Пишется это вот так:

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

      Элемент html – это контейнер для всего содержимого HTML-страницы и он не принадлежит ни к одной контентной модели документа.

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

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

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

      Добавьте прямо сейчас к своей заготовке с элементом doctype парный элемент .

      В итоге мы получаем вот такой код:

      Переходим к следующему шагу и создадим элемент head.

      Автор:
      Дмитрий Ченгаев

      Делюсь своим опытом в веб-разработке, чтобы вы реализовали свои идеи и проекты.

      Илон Маск рекомендует:  strcmp - Сравнение строк, безопасное для данных в двоичной форме
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL