Дизайн XML - Как?

Question

В настоящее время мы работаем над дизайном приложения RESTful. Мы выбрали XML в качестве основного представления. У меня есть следующие вопросы относительно проектирования / моделирования данных приложения в XML.

1. Каковы подходы к моделированию данных в XML? Это хорошая идея, чтобы начать с нуля, а затем оценить использование стандартных схем XML или наоборот?
2. Где найти информацию обо всех стандартных схемах XML?
3. Должен ли я начать думать о пространствах имен с самого начала или это то, что я могу отложить на потом?
4. Наконец, хорошо ли начинать сначала с разработки схем XML или начать с документа XML, а затем определить схему?

Примечание. Я уже рассматривал связанный с этим вопрос о stackoverflow ( Каковы наилучшие практики для разработки схем XML? ), но, похоже, он не отвечает на поставленные выше вопросы.

Answer 1

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

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

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

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

Answer 2

1. С XML-схемой можно многое сделать, например, абстрактный класс, перечисление и т. Д. См. XML-схема, часть 0: учебник для начинающих, второе издание . Если вы заботитесь о совместимости, старайтесь держаться подальше от определенных типов данных .
2. Список языков разметки XML перечисляет некоторые известные схемы. Для сервиса POX on REST я думаю, что вы будете делать свой собственный.
3. Пока это гарантированно уникально, само фактическое имя не имеет значения. Включите даты для будущих версий.
4. Я думаю, у вас должны быть идеи о том, как должен выглядеть итоговый XML-документ.

Одна вещь, на которую следует обратить внимание при проектировании услуг, это то, что она отличается от разработки класса / объекта, и вам нужно больше думать с точки зрения обмена документами. Это иногда называется Конечно-* . В OO-мире вы будете обмениваться сериями вызовов методов между коллегами, но в SOA вы будете избегать болтливости и попытаетесь вставить большую часть необходимой информации в документ, что-то вроде заполнения налоговой формы.

Answer 3

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

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

Рекомендуется гетерогенный подход к проектированию. Обратитесь к http://technologyandleadership.com/three-schema-design-approaches/, чтобы узнать, как реализовать этот подход к проектированию для вашего проекта

Answer 4

Я согласен с тем, что вам следует сначала разработать свое приложение и решить, какую информацию вам необходимо обменять.

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

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