Почему порядок узлов важен в XML?

Question

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

Для примера, это будет правильно (xml значительно упрощено)

<transaction>
    <address>1 main st</address>
    <amount>100</amount>
    <orderId>1234</orderId>
</transaction>

но это вернет ошибку

<transaction>
    <address>1 main st</address>
    <orderId>1234</orderId>
    <amount>100</amount>
</transaction>

Сначала я подумал, что так можно будет хранить вещи в форме списка / массива и иметь индексы всегда ссылающиеся на один и тот же узел.Я понимаю, почему отправка узлов с одинаковым именем в том же порядке важна, как объяснено в этом вопросе .Однако некоторые узлы могут быть пропущены:

<transaction>
    <amount>100</amount>
    <orderId>1234</orderId>
</transaction>

Таким образом, в третьем примере, сумма и orderId теперь будут в [0] и [1], а не в [1] и [2] вПервый (правильный) пример.

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

Может кто-нибудь объяснить мне, почему порядок, в котором я даю ноды, имеет значение?Или я имею дело со старым и сварливым API?

Answer 1

Порядок узлов, очевидно, имеет значение в XML, как это:

<p>
   <span>This wouldn't make much sense</span>
   <span>if the order of these nodes were reversed.</span>
</p>

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

Представьте себе класс с частным полем Person, которое предоставляет свойства PersonID и Name. Установщик PersonID создает личный экземпляр Person, а установщик Name устанавливает свойство Name в поле частного Person. В этом случае установка Name перед установкой PersonID завершится неудачно, поскольку Person еще не существует.

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

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

Answer 2

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

Answer 3

Ответ лежит в XML-DTD / Schema . Базовая схема, определенная в API, приводит к ошибке. Хотя я полагаю, что я не хочу преподавать XML здесь, все же взгляд на следующее прояснит ситуацию.

XML имеет две точки, которые следует учитывать:

• Хорошо сформированный XML: идеальный синтаксис
• Допустимый XML: идеально подходит для DTD (определение типа документа) / Схема

Очки о DTD: Предложенный DTD на ваш вопрос:

<!DOCTYPE transaction
[
<!ELEMENT address (#PCDATA)>
<!ELEMENT amount (#PCDATA)>
<!ELEMENT orderid (#PCDATA)>
]>

Выше приведено предлагаемое DTD для структуры, которую вы указали в вопросе. Поскольку вы имеете дело с определенным API, в нем уже есть структура такого типа. Альтернативой этому является XML-схема .

Очки о схеме XML:

<xs:element name="transaction">    
<xs:complexType>
  <xs:sequence>
    <xs:element name="address" type="xs:string"/>
    <xs:element name="amount" type="xs:string"/>
    <xs:element name="orderid" type="xs:string"/>
  </xs:sequence>
</xs:complexType>
</xs:element>

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

Answer 4

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

consumeTransation:
    consumeAddressIfPresent;
    consumeAmountIfPresent;
    consumeOrderIDIfPresent;

Что более важно, использование XML-схема для определения структуры делает заказ болеескорее всего, будет требование .Это связано с тем, что XML-схема имеет более богатую поддержку упорядоченных списков (xs:sequence), чем для неупорядоченных списков (xs:all).Последние имеют ограничения по вхождению, их сложнее проверить, и они не расширяемы в том виде, в котором они представлены.Некоторое из этого улучшено в XML Schema 1.1, но большинство инструментов / API пока не существует.

Answer 5

Код быстрее и проще зависит от порядка элементов.

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

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