То, что разработчик должен знать прежде, чем создать новый XML, основывало формат или язык? [закрытый]

В статье блога Использование и злоупотребление XML есть несколько хороших советов, среди прочего:

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

<key>Name</key><string>Audiobooks</string>
<key>Playlist ID</key><integer>94</integer>

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

<name id="94">Audiobooks</name>

Определенно, вы захотите изучить XPath в тот или иной момент. Это (как мне кажется) лучший способ выбора XML.

Определенно используйте схему, будь то XSD или RELAX NG.

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

во-вторых, вам нужно знать хотя бы немного о xsd и xslt. и немного больше о xpath / xquery, поскольку пользователи вашего стандарта, вероятно, будут использовать их для обработки своего контента.

в-третьих, я предлагаю вам как можно глубже изучить другие стандарты, основанные на XML, чтобы увидеть, как они были созданы. Стандарт XHTML очень хорош для изучения, поскольку это самый старый стандарт XML, и его развитие было обусловлено фактическим использованием в течение длительного периода времени. Кроме того, вы можете рассмотреть возможность изучения atom и rss, xsd (на этот раз в качестве стандарта, а не технологии) и микроформатов

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

1. Изучение схемы XML
   • Не пытайтесь сделать схему удобной, разрешая элементы в разном порядке.
   • Сделайте вашу схему доступной через Интернет. Вам не нужно размещать его по URL-адресу, связанному с вашим пространством имен, но это может быть неплохо.
2. Изучите пространства имен XML
3. Изучите XPATH
4. Разберитесь, что такое XML INFOSET, и узнайте, что значит сериализовать его.

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

Имена элементов должны быть короткими, но / и описательными.

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

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

Убедитесь, что у вас версия схемы, и всегда старайтесь избегать критических изменений, но / и разрешайте обратную совместимость с новыми версиями.

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

• Пространства имен : что они собой представляют, когда и когда их не использовать, как они влияют на синтаксический анализ
• Проверка схемы / XSD . Одно из преимуществ XML состоит в том, что он легко проверяется, поэтому я ожидаю, что схема будет проверять все, что называет себя стандартным
• XPath и другими механизмами запросов ( XQuery встречается редко и имеет отношение к XPath, но все же является собственным стандартом, чтобы хотя бы быстро взглянуть на него)
• Общие сведения о экранировании материалов , CDATA или других способах
• Когда использовать атрибуты или ..когда использовать дочерние элементы
• Возможные родственные стандарты. Это не строго связано, но, например, если вам нужно добавить подпись документа, для этого уже есть стандарты (например, XML-подпись ). Обычно каждый раз, когда вы добавляете функцию, быстро проверяйте, существует ли уже стандарт, и решайте, стоит ли его адаптировать. Изобретать колесо можно, если вы хотя бы знаете, почему все остальные колеса - отстой.

IBM выпустила серию статей о Принципах проектирования XML , в которой содержится много истин. Лучший совет - никогда не бывает единственного правильного пути, кроме:

• Будьте лаконичны в выборе дизайна, если вы выбираете маршрут A, выбирайте его везде. то есть: , если вы используете элемент оболочки для хранения , используйте элемент оболочки везде для коллекций.

• Будьте максимально краткими, чтобы не перегружать текст.Предполагается, что XML будет доступен для чтения нам, людям.

• По возможности избегайте пространств имен
• Это ДОЛЖНО быть проверено через схему.