Почему XML имеет такие подробные закрывающие теги?

Да, это, вероятно, не должно меня задевать.

Но это так!

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

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

Например:

<thisIsSomewhatLong>
    Hello, world!
</thisIsSomewhatLong>

... гораздо более подробный, чем:

<thisIsSomewhatLong>
    Hello, world!
</>

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

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

ОТВЕТЫ

Ответ 1

Поскольку он улучшает читаемость, родившийся XML не был эффективным или лаконичным, просто чтобы было легко работать с.. и если вы думаете, что </> не создаст двусмысленности, это просто потому что вы отступаете от кода. Если вы не укажете отступ (что является действительно более слабым ограничением по сравнению с именем в закрывающем теге), тогда это становится беспорядком.

Простой пример?

<A><B><C><D>foo</><D>bar</></><H>baz</></></>

Вы думаете, что это так читаемо? Трудно понять, где <H> без учета закрывающих тегов.

Ответ 2

Я вижу одно большое преимущество: отсутствующие закрывающие теги сразу улавливаются (человеком или компьютером), а не получают ошибку, например Insufficient closing tags provided; please read through your 1000 line file and figure out where it happened.

Ответ 3

То, что вы предлагаете, эквивалентно S-выражению. Вы знаете, что все Lisp написано, например. (thisisSomewhatLong Hello, world!). Действительно, есть некоторые, которые утверждают, что это лучше, потому что это намного менее многословно. Они правы, они менее подробные. Но нравится это или нет, эта многословие также имеет свои преимущества. Прежде всего, это позволяет раннее обнаружение ошибок. С SExprs или аналогичным, пропуская близкий парик или имея слишком много, это означает, что "есть несогласованные parens, удача, находящая вас" (если вам повезет - если вы допустили такую ​​ошибку дважды, она проявляется и может легко ввернуть все разметка - хотя она может, конечно, создать структуру, которая не соответствует схеме (при условии, что у вас есть что-то вроде этого), что может позволить немного улучшить отчет об ошибках).

Также см. "XML не S-выражения" .

Ответ 4

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

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

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

Ответ 5

Риск состоит в том, чтобы потеряться в

    ...
    ...
    ...
    </>
   </>
  </>
 </>
</>

BTW, он может быть проверен отлично без имен конечных тегов.

Ответ 6

Я полагаю, что это для удобства чтения, как упомянуто выше. Однако он нарушает принцип DRY и, таким образом, вводит источник ошибок, и, разумеется, он раздувает ваш размер документа, что вдвойне отстойно, если вы передаете его по сети, что является обычной практикой в ​​наши дни.

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

<color>red</colour>

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

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