Мы снова продолжаем изучение XML и в данной статье познакомимся с такими конструкциями XML, как процессинговые инструкции, комментарии, атрибуты и другие элементы XML. Эти элементы являются базовыми и позволяют гибко, в четком соответствии со стандартом размечать документы абсолютно любой сложности.
Некоторые моменты, такие как теги XML, мы уже частично рассматривали в предыдущей статье « ». Теперь мы еще раз затронем эту тему и разберем ее более подробно. Это сделано специально, чтобы вам было проще представить всю картину конструкций XML.
Как уже говорилось в предыдущей статье, теги в XML не просто размечают текст, как это бывает в HTML, а выделяют отдельные элементы (объекты). В свою очередь элементы иерархически организуют информацию в документе, что в свою очередь и сделало их основными структурными единицами языка XML.
В XML элементы могут быть двух типов – пустые и непустые. Пустые элементы не содержат в себе никаких данных, таких как текст или другие конструкции. В отличие от пустых элементов, непустые могут содержать в себе любые данные, такие как текст или другие элементы и конструкции языка XML. Чтобы понять суть вышесказанного, давайте рассмотрим примеры пустых и непустых элементов XML.
Пустой элемент XML
Непустой элемент XML
Как мы видим с примера выше, главным отличием пустых элементов от непустых является то, что они состоят только из одного тега. Кроме того стоит также заметить, что в XML все имена регистрозависимые. Это означает, что имена myElement, MyElement, MYELEMENT и т.д. различаются между собой, поэтому данный момент стоит сразу запомнить, чтобы избежать ошибок в будущем.
Итак, с элементами мы разобрались. Теперь давайте перейдем к следующему моменту, такому как логическая организация XML-документов.
Как вы помните, основной конструкцией языка XML являются элементы, которые могут содержать в себе другие вложенные конструкции и тем самым формировать иерархическую структуру в виде дерева. В этом случае родительский элемент будет корнем, а все остальные дочерние элементы будут ветками и листьями дерева XML.
Чтобы было проще понять суть вышесказанного, давайте рассмотрим следующее изображение с примером.
Как мы видим, организация XML-документа в виде дерева является довольно простой структурой для обработки. При этом выразительная сложность самого дерева достаточно велика. Именно древовидное представление является наиболее оптимальным способом описания объектов в XML.
В XML элементы могут содержать также и атрибуты с присвоенными им значениями, которые помещаются в одинарные или двойные кавычки. Атрибут для элемента задается следующим образом:
В данном случае использовался атрибут с именем «attribute» и значением «value». Тут стоит сразу заметить, что атрибут XML обязательно должен содержать какое-то значение и не может быть пустым. В противном случае код будет некорректным с точки зрения XML.
Также стоит обратить внимание на использование кавычек. Значение атрибутов может заключаться как в одинарные, так и в двойные кавычки. Кроме того возможно также использование одних кавычек внутри других. Для демонстрации рассмотрим следующие примеры.
Прежде чем приступить к рассмотрению других конструкций XML стоит также заметить, что при создании атрибутов в качестве значений не могут использоваться такие специальные символы, как амперсанд «&» или угловые скобки «<>». Данные символы зарезервированы в качестве управляющих («&» — сущность, а «<» и «>» открывают и закрывают тег элемента) и не могут быть использованы в «чистом виде». Для их использования нужно прибегать к замене спецсимволов.
В языке XML есть возможность включения в документе инструкций, которые несут определенную информацию для приложений, которые будут обрабатывать тот или иной документ. Инструкции по обработке в XML создаются следующим образом.
Как видно с примера выше, в XML инструкции по обработке заключаются в угловые кавычки со знаком вопроса. Это немного напоминает обычный , который мы рассматривали в первых уроках по PHP. В первой части процессинговой инструкции определяется приложение или система, которой предназначена вторая часть этой инструкции или ее содержимое. При этом инструкции по обработке действительны только для тех приложений, которым они адресованы. Примером процессинговой инструкции может быть следующая инструкция.
Стоит заметить, что в XML есть особая конструкция, которая очень сильно похожа на инструкцию по обработке, но сама она такой не является. Речь идет об XML-декларации, которая передает обрабатывающему программному обеспечению некоторую информацию о свойствах XML-документа, таких как кодировка, версия языка в соответствии с которым написан данный документ и т.д.
Как видно с примера выше, XML-декларация содержит так называемые псевдоатрибуты, которые очень похожи на обычные атрибуты, о которых мы говорили чуть выше. Дело в том, что по определению XML-декларация и инструкции по обработке не могут содержать атрибутов, поэтому данные объявления назвали псевдоатрибутами. Это стоит запомнить на будущее во избежание разнообразных ошибок.
Поскольку мы разобрались с псевдоатрибутами, то давайте рассмотрим, что же они означают.
Ну а теперь перейдем к заключающей части статьи и рассмотрим такие конструкции XML как комментарии и секции CDATA.
Мы снова продолжаем изучение XML и в данной статье познакомимся с такими конструкциями XML, как процессинговые инструкции, комментарии, атрибуты и другие элементы XML. Эти элементы являются базовыми и позволяют гибко, в четком соответствии со стандартом размечать документы абсолютно любой сложности.
Некоторые моменты, такие как теги XML, мы уже частично рассматривали в предыдущей статье « ». Теперь мы еще раз затронем эту тему и разберем ее более подробно. Это сделано специально, чтобы вам было проще представить всю картину конструкций XML.
Как уже говорилось в предыдущей статье, теги в XML не просто размечают текст, как это бывает в HTML, а выделяют отдельные элементы (объекты). В свою очередь элементы иерархически организуют информацию в документе, что в свою очередь и сделало их основными структурными единицами языка XML.
В XML элементы могут быть двух типов – пустые и непустые. Пустые элементы не содержат в себе никаких данных, таких как текст или другие конструкции. В отличие от пустых элементов, непустые могут содержать в себе любые данные, такие как текст или другие элементы и конструкции языка XML. Чтобы понять суть вышесказанного, давайте рассмотрим примеры пустых и непустых элементов XML.
Пустой элемент XML
Непустой элемент XML
Как мы видим с примера выше, главным отличием пустых элементов от непустых является то, что они состоят только из одного тега. Кроме того стоит также заметить, что в XML все имена регистрозависимые. Это означает, что имена myElement, MyElement, MYELEMENT и т.д. различаются между собой, поэтому данный момент стоит сразу запомнить, чтобы избежать ошибок в будущем.
Итак, с элементами мы разобрались. Теперь давайте перейдем к следующему моменту, такому как логическая организация XML-документов.
Как вы помните, основной конструкцией языка XML являются элементы, которые могут содержать в себе другие вложенные конструкции и тем самым формировать иерархическую структуру в виде дерева. В этом случае родительский элемент будет корнем, а все остальные дочерние элементы будут ветками и листьями дерева XML.
Чтобы было проще понять суть вышесказанного, давайте рассмотрим следующее изображение с примером.
Как мы видим, организация XML-документа в виде дерева является довольно простой структурой для обработки. При этом выразительная сложность самого дерева достаточно велика. Именно древовидное представление является наиболее оптимальным способом описания объектов в XML.
В XML элементы могут содержать также и атрибуты с присвоенными им значениями, которые помещаются в одинарные или двойные кавычки. Атрибут для элемента задается следующим образом:
В данном случае использовался атрибут с именем «attribute» и значением «value». Тут стоит сразу заметить, что атрибут XML обязательно должен содержать какое-то значение и не может быть пустым. В противном случае код будет некорректным с точки зрения XML.
Также стоит обратить внимание на использование кавычек. Значение атрибутов может заключаться как в одинарные, так и в двойные кавычки. Кроме того возможно также использование одних кавычек внутри других. Для демонстрации рассмотрим следующие примеры.
Прежде чем приступить к рассмотрению других конструкций XML стоит также заметить, что при создании атрибутов в качестве значений не могут использоваться такие специальные символы, как амперсанд «&» или угловые скобки «<>». Данные символы зарезервированы в качестве управляющих («&» — сущность, а «<» и «>» открывают и закрывают тег элемента) и не могут быть использованы в «чистом виде». Для их использования нужно прибегать к замене спецсимволов.
В языке XML есть возможность включения в документе инструкций, которые несут определенную информацию для приложений, которые будут обрабатывать тот или иной документ. Инструкции по обработке в XML создаются следующим образом.
Как видно с примера выше, в XML инструкции по обработке заключаются в угловые кавычки со знаком вопроса. Это немного напоминает обычный , который мы рассматривали в первых уроках по PHP. В первой части процессинговой инструкции определяется приложение или система, которой предназначена вторая часть этой инструкции или ее содержимое. При этом инструкции по обработке действительны только для тех приложений, которым они адресованы. Примером процессинговой инструкции может быть следующая инструкция.
Стоит заметить, что в XML есть особая конструкция, которая очень сильно похожа на инструкцию по обработке, но сама она такой не является. Речь идет об XML-декларации, которая передает обрабатывающему программному обеспечению некоторую информацию о свойствах XML-документа, таких как кодировка, версия языка в соответствии с которым написан данный документ и т.д.
Как видно с примера выше, XML-декларация содержит так называемые псевдоатрибуты, которые очень похожи на обычные атрибуты, о которых мы говорили чуть выше. Дело в том, что по определению XML-декларация и инструкции по обработке не могут содержать атрибутов, поэтому данные объявления назвали псевдоатрибутами. Это стоит запомнить на будущее во избежание разнообразных ошибок.
Поскольку мы разобрались с псевдоатрибутами, то давайте рассмотрим, что же они означают.
Ну а теперь перейдем к заключающей части статьи и рассмотрим такие конструкции XML как комментарии и секции CDATA.
На работе нас просят создать файлы XML для передачи данных в другое автономное приложение, которое затем создаст второй XML файл для возврата, чтобы обновить некоторые наши данные. Во время процесса мы обсуждали с командой другого приложения структуру XML файла.
Образец, с которым я столкнулся, по существу выглядит примерно так:
Другая команда заявила, что это не отраслевой стандарт, и что атрибуты должны использоваться только для метаданных. Они предложили:
Причина, по которой я предположил, что первый заключается в том, что размер создаваемого файла намного меньше. Будет около 80000 элементов, которые будут в файле во время передачи. На самом деле предложение действительно в три раза больше, чем я предложил. Я искал загадочный "отраслевой стандарт", который был упомянут, но ближайший, который я мог найти, - это атрибуты XML, которые должны использоваться только для метаданных, но сказал, что дискуссия о том, что было фактически метаданными.
После долгого объяснения (извините), как вы определяете, что такое метаданные, и при разработке структуры документа XML, как вы должны решить, когда использовать атрибут или элемент?
20 ответов
Я использую это правило:
Итак, ваш близок. Я бы сделал что-то вроде:
EDIT : обновлен исходный пример, основанный на обратной связи ниже.
Некоторые из проблем с атрибутами:
Если вы используете атрибуты в качестве контейнеров для данных, вы получаете документы, которые трудно читать и поддерживать. Попытайтесь использовать элементы для описания данных. Используйте атрибуты только для предоставления информации, не относящейся к данным.
Не заканчивайте так (это не то, как следует использовать XML):
"XML" означает "расширяемый язык разметки". Язык разметки подразумевает, что данные представляют собой текст, помеченный метаданными о структуре или форматировании.
XHTML - пример XML, используемый так, как он был предназначен:
El Jefe insists that you MUST complete your project by Friday.
Здесь различается различие между элементами и атрибутами. Текстовые элементы отображаются в браузере, а атрибуты - инструкции о том, как их отображать (хотя есть несколько тегов, которые не работают таким образом).
Путаница возникает, когда XML используется не как язык разметки, а как язык сериализации данных, в котором различие между "данными" и "метаданными" более неопределенно. Таким образом, выбор между элементами и атрибутами более или менее произволен, за исключением вещей, которые не могут быть представлены атрибутами (см. Ответ feenster).
XML - это соглашение. Сначала отложите все существующие схемы XML или установленные соглашения в рамках вашего сообщества или отрасли.
Если вы действительно в ситуации, чтобы определить свою схему с нуля, вот некоторые общие соображения, которые должны сообщать о выборе элемента vs :
Это может зависеть от вашего использования. XML, который используется для представления данных, созданных из базы данных, может хорошо работать, и в конечном итоге значения полей помещаются как атрибуты.
Однако XML, используемый в качестве транспорта сообщений, часто лучше использовать большее количество элементов.
Например, скажем, что у нас был этот XML, как предлагается в ответе: -
Теперь мы хотим отправить элемент ITEM на устройство для печати штрих-кода, однако есть выбор типов кодирования. Как мы представляем требуемый тип кодирования? Неожиданно мы несколько с опозданием понимаем, что штрих-код не является одним автоматическим значением, а скорее может быть квалифицирован с кодировкой, требуемой при печати.
Дело в том, что если вы не строите какой-либо XSD или DTD вместе с пространством имен, чтобы исправить структуру в камне, вам может быть лучше всего оставить свои варианты открытыми.
IMO XML наиболее полезен, когда его можно сгибать, не нарушая при этом существующий код.
Предпочтение атрибутов заключается в следующем:
Я добавил, когда технически возможно, потому что бывают случаи, когда использование атрибутов невозможно. Например, выбор набора атрибутов. Например использование (startDate и endDate) xor (startTS и endTS) невозможно с текущим языком схемы
Если XML Schema начинает разрешать ограниченную или расширенную модель контента "все", я бы, вероятно, сбросил ее
Нет универсального ответа на этот вопрос (я активно участвовал в создании спецификации W3C). XML может использоваться для многих целей - текстовые документы, данные и декларативный код являются тремя наиболее распространенными. Я также использую его как модель данных. Существуют аспекты этих приложений, где атрибуты более распространены и другие, где дочерние элементы более естественны. Существуют также функции различных инструментов, которые упрощают или упрощают их использование.
XHTML - это одна область, где атрибуты имеют естественное использование (например, в class= "foo"). Атрибуты не имеют порядка, и это может облегчить для некоторых людей разработку инструментов. Атрибуты OTOH сложнее вводить без схемы. Я также нахожу атрибуты с именами (foo: bar = "zork"), которые зачастую сложнее управлять в различных наборах инструментов. Но посмотрите на некоторые из языков W3C, чтобы увидеть смесь, которая является общей. SVG, XSLT, XSD, MathML - некоторые примеры хорошо известных языков, и все они имеют богатый запас атрибутов и элементов. Некоторые языки даже допускают больше, чем один способ, например,
Обратите внимание, что они НЕ эквивалентны синтаксически и требуют явной поддержки в инструментах обработки)
Моим советом было бы взглянуть на обычную практику в ближайшей к вашей области, а также рассмотреть, какие инструменты вы можете применить.
Наконец, убедитесь, что вы различаете пространства имен из атрибутов. Некоторые XML-системы (например, Linq) представляют пространства имен в качестве атрибутов API. ИМО это уродливое и потенциально запутанное.
Другие рассмотрели, как различать атрибуты от элементов, но с более общей точки зрения, помещая все в атрибуты, потому что это делает полученный XML меньше ошибочным.
XML не предназначен для компактности, но для переносимости и чтения человеком. Если вы хотите уменьшить размер данных в пути, используйте другое (например, буферы протокола Google).
Это спорно так или иначе, но ваши коллеги правы в том смысле, что XML должен быть использован для "накрутку" или мета-данных вокруг фактических данных. Со своей стороны, вы правы в том, что иногда трудно решить, где линия между метаданными и данными при моделировании вашего домена в XML. На практике я делаю вид, что что-то в разметке скрыто, и только данные вне разметки читаются. Имеет ли этот документ какой-то смысл?
XML, как известно, громоздкий. Для транспортировки и хранения настоятельно рекомендуется сжатие, если вы можете позволить себе вычислительную мощность. XML сжимается хорошо, иногда феноменально хорошо, из-за его повторяемости. У меня было сжатие больших файлов до менее чем 5% от их первоначального размера.
Еще один момент, чтобы укрепить вашу позицию, заключается в том, что в то время как другая команда спорит о стиле (в том, что большинство инструментов XML будут обрабатывать полностью атрибутный документ так же просто, как и документ all-# PCDATA), вы утверждаете практичность. Хотя стиль не может быть полностью проигнорирован, технические достоинства должны нести больше веса.
Использовать элементы для данных и атрибутов для метаданных (данные о данных элемента).
Если элемент отображается как предикат в ваших строках выбора, у вас есть хороший знак того, что он должен быть атрибутом. Аналогично, если атрибут никогда не используется как предикат, то, возможно, это не полезные метаданные.
Помните, что XML должен быть машиносчитываемым, не читаемым человеком, а для больших документов XML сжимается очень хорошо.
Как насчет того, чтобы использовать нашу интуицию, ориентированную на твердую заработную плату? Обычно я считаю, что прямо думать о том, что является объектом и является атрибутом объекта или объекта, на который он ссылается.
Каким бы интуитивно не было смысла, поскольку объекты должны вписываться в элементы. Его атрибуты (или свойства) будут атрибутами для этих элементов в xml или дочернем элементе с атрибутом.
Я думаю, что для более простых случаев, как в примере, аналогия объектной ориентации работает нормально, чтобы определить, что является элементом и который является атрибутом элемента.
вопрос в миллион долларов!
Вначале не беспокойтесь о производительности. вы будете удивлены тому, как быстро оптимизированный синтаксический анализатор xml будет копировать ваш XML файл. что более важно, каков ваш дизайн на будущее: по мере развития XML, как вы будете поддерживать свободную связь и функциональную совместимость?
более конкретно, вы можете сделать контентную модель элемента более сложной, но сложнее расширить атрибут.
В основном это вопрос предпочтения. Я использую Elements для группировки и атрибуты для данных, где это возможно, поскольку я считаю это более компактным, чем альтернатива.
Например, я предпочитаю.....
Вместо....
Однако, если у меня есть данные, которые не могут легко отображаться внутри, например, 20-30 символов или содержат много кавычек или других символов, которые нужно экранировать, я бы сказал, что это время, чтобы разбить элементы... возможно, с блоками CData.
Здравствуйте, уважаемые посетители сайта сайт! Продолжим тему о языке разметки XML и рассмотрим использование атрибутов. Атрибуты в XML элементах могут присутствовать, также как в HTML. Атрибуты обеспечивают дополнительную информацию об элементе.
В HTML атрибуты обеспечивают дополнительную информацию об элементах:
Значения атрибутов в xml всегда должны быть заключены в кавычки. Могут использоваться как одинарные, так и двойные кавычки. Для указания пола элемента человек (person) можно написать так:
Если значение атрибута само по себе содержит двойные кавычки, вы можете использовать одинарные кавычки, как в этом примере:
Взгляните на следующие примеры:
В первом примере пол (sex) является атрибутом. В последнем, sex – это элемент. Оба примера предоставляют одну и ту же информацию.
Нет правил о том, когда использовать атрибуты, а когда элементы. Атрибуты удобны в HTML. В XML я советую их избегать. Используйте вместо них элементы.
Следующие три XML документа содержат в точности одинаковую информацию:
XML атрибут date используется в первом примере:
Расширенный элемент date используется в третьем: (ЭТО МОЙ ЛЮБИМЫЙ СПОСОБ):
Некоторые из проблем с использованием xml атрибутов:
Не делайте подобным образом:
body="Не забудь мне позвонить завтра!"> |
Не забудь мне позвонить завтра! ОК |
Атрибуты id выше используются для идентификации разных заметок. Они не являются частью заметки самой по себе.
Что я пытаюсь здесь сказать – метаданные (данные о данных) следует хранить как xml-атрибуты, а сами данные хранить как элементы.
Спасибо за внимание!.
Как и в HTML, XML элементы могут иметь атрибуты. При этом значение атрибутов в XML и правило их создания во многом похожи на .
Атрибуты предоставляют дополнительную информацию об элементе.
В HTML атрибуты предоставляют некоторую дополнительную информацию об элементе:
Атрибуты часто предоставляют информацию, не являющуюся частью данных. В примере ниже тип файла не зависит от данных, но эта информация может быть важна для приложений, которые будут манипулировать этим элементом:
Значение атрибута всегда должно заключаться в кавычки. Это могут быть либо двойные, либо одинарные кавычки. Например, пол персонажа можно записать так:
либо так:
Если значение атрибута само содержит двойные кавычки, то можно использовать одинарные кавычки. Например:
либо использовать символы сущностей:
Посмотрите на следующие примеры:
Пример №1
Пример №2
В первом примере пол указан в атрибуте. Во втором, пол записан, как элемент. Оба примера предоставляют одну и ту же информацию.
Нет правил, регулирующих то, когда использовать атрибуты, а когда элементы. Атрибуты широко используются в HTML. В XML, на мой взгляд, лучше их избегать, и вместо них использовать элементы.
Следующие три XML документа содержат совершенно одинаковую информацию:
Дата записана, как атрибут :
Дата записана, как элемент :
Дата записана, как расширенный элемент (На мой взгляд наилучший вариант):
При использовании атрибутов возникают некоторые проблемы:
Никогда не используйте следующие конструкции:
Иногда элементам присваивают идентификаторы. Эти идентификаторы используются для идентификации XML элементов в точности также, как идентификационные атрибуты в HTML. Следующий пример демонстрирует это:
В приведенном примере атрибут id используется для идентификации разных заметок. Эта информация не является частью самой заметки.
Главная мысль всего сказанного это то, что метаданные (данные о данных) следует записывать, как атрибуты, а сами данные, как элементы.
