Является ли порядок, в котором элементы общего родителя отображают в XML значимую часть данных, захваченных XML-документом, или порядок не указан как имеющий смысл? Например, рассмотрим два документа XML:
<people>
<person name="sam"/>
<person name="juni"/>
</people>
и
<people>
<person name="juni"/>
<person name="sam"/>
</people>
Рассматриваются ли эти документы как данные идентичные, или это разница в порядке захвата?
Порядок элементов значим в XML, поэтому в вашем примере два документа отличаются друг от друга. Однако порядок атрибутов не имеет значения.
<people>
<person name="kathy" id="1"/>
</people>
Это точно так же, как:
<people>
<person id="1" name="kathy"/>
</people>
Они не идентичны - зависит ли последовательность от программы или пользователя, который ее обрабатывает. Например, последовательность элементов в документе XHTML определяет, как они отображаются в браузере, а поисковые системы используют позицию в документе для оценки относительной важности данных.
Порядок потенциально важен, но зависит от того, что передается.
В XHTML, например, порядок чрезвычайно важен - если у вас были абзацы сестры в случайном порядке, это было бы очень запутанно!
Во многих других случаях это несущественно.
XML - это всего лишь способ представления дерева узлов. Сам XML говорит, что порядок важен: API должны сохранять порядок, например, но это зависит от того, что производит/интерпретирует данные, которые действительно заботятся о порядке или нет.
Спецификация XML эффективно должна "ошибаться на стороне заказа" - легко игнорировать порядок, если вам это неинтересно, но это боль, чтобы восстановить порядок, если API-интерфейсы решили переключить ситуацию. (Вам нужно будет поместить заказ в атрибуты и т.д.)
Хотя упорядочение атрибутов XML не имеет существенного значения в отношении стандарта XML, текстовое представление XML делает по необходимости атрибуты в определенном порядке. Это может быть проблемой для таких вещей, как XML Signature, которая генерирует цифровую подпись для XML-документов. Другой порядок атрибутов создавал бы другую подпись, которая явно неверна.
Для этой (и других) причин теперь существует стандарт для канонизации XML, который определяет правила для реорганизации XML-документов, так что они сохраняют один и тот же информационный контент, но имеют такие вещи, как пропуски, объявления пространства имен и атрибуты, переупорядоченные в предсказуемым способом.
От xml.com
Канонический XML требует включения заявлений пространства имен и атрибуты в восходящей лексикографии порядок.
В соответствии с в этой статье версия стандарта 1.0 не требует даже того, чтобы синтаксические анализаторы сообщали братьям и сестрам в том порядке, в каком они появляются в документ. В этом свете они не будут считаться разными, так как оба они есть. Возможно, это изменилось, так что другие ответы предназначены для новых версий XML.
С чисто точки зрения действительности XML это зависит от схемы, если таковая имеется, которая описывает, какие правила предназначены для форматирования XML.
Тем не менее, порядок должен быть сохранен (см. 2.1.1 в http://www.w3.org/TR/xml-infoset/), но является ли оно "важным" для приложения его автору.
В рамках схемы порядок может быть неважным с использованием компоновщика xs:all, хотя я не уверен, что это влияет на сохранение захваченного порядка, т.е. я все же ожидал бы, что порядок при возникновении/сериализации поддерживаются процессорами XML.
Однако в 1.0 этот композитор добавляет ограничение на дочерние элементы, так что они должны встречаться 0 или 1 раз. В XSD 1.1 это ограничение удаляется, что упрощает контрактное определение того, что порядок не важен, эффективно xs:all стал неупорядоченной версией xs:sequence.
Из-за чрезмерно ограничивающего компоновщика 1.0 xs:all необходимо использовать упорядоченный компоновщик xs:sequence. Таким образом, порядок часто искусственно налагался.
Принятие 1.1 поставщиками библиотек проверки достоверности выполняется медленно.
Таким образом, API должны учитывать порядок при разработке новых элементов. Я не знаю какой-либо XML-схемы сериализации, которая может работать с 1.1, и вы должны предположить, что ваши клиенты будут использовать 1.0 и будут проверять входящие сообщения 1.1 с 1.0 правилами и дросселями.
Лука
XML 1.0 Spec ничего не говорит о порядке элементов с одинаковыми именами как дочерние элементы одного и того же родительского элемента. Похоже, проблема - undefined.
Однако большинство синтаксических анализаторов XML и API сохраняют последовательность, указанную в текстовом представлении. Таким образом, можно реализовать приложения, которые заботятся о порядке элементов. И де-факто ответ на ваш вопрос: Да, порядок имеет значение. Эти два примера различны.
Присмотревшись внимательнее, вам нужно выяснить, что такое ваш вариант использования. Если ваш XML должен взаимодействовать с разными (возможно, сторонними) приложениями, вы всегда должны считать, что этот порядок имеет значение. Если у вас есть полный контроль над производством и потреблением приложения, вы можете расслабиться это правило.
Как всегда, вам придется судить.
Есть разница. Вы можете использовать различные XML API для обработки элементов в последовательности или поиска элемента по индексу. Конечно, порядок может не иметь значения в вашем конкретном примере, но это зависит от семантики данных.
Порядок захвачен.
Я думаю, что их следует считать одинаковыми, но это действительно зависит от программного обеспечения или человека, которые его читают. XML - это всего лишь способ записи данных. Приложение определяет, как эти данные используются и, следовательно, значительная часть значения.
Если ваше приложение читается во всех элементах пользователя, а затем по алфавиту их по имени, то порядок в документе XML не имеет смысла. Если ваше приложение читает их и назначает места в том же порядке, люди появляются в XML, тогда порядок очень важен.
Это приложение, которое использует данные. Если порядок важен, его следует описать в спецификациях для людей, генерирующих файлы.
http://www.ibm.com/developerworks/xml/library/x-eleord.html
Возможно, обсуждение в статье поможет ответить на ваш вопрос. Поскольку ваш вопрос несколько открыт, я не уверен, что он касается вас.