Хорошие или общие соглашения об именах для URI пространства имен XML - PullRequest
15 голосов
/ 07 января 2011

Я ищу некоторые идеи для хороших соглашений об именах для целевых пространств имен xsd.

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

Есть ли у вас какой-либо опыт из прошлых созданий XML-схем относительно того, что является хорошим и работающим решением? Я пытался найти информацию в Интернете, но в большинстве примеров просто используются очень общие целевые пространства имен, такие как "http://exampleSchema" и т. П. Я на самом деле пытаюсь найти примеры из реальной жизни.

1 Ответ

16 голосов
/ 07 января 2011

Собственные методы W3C по выбору долгоживущих URI являются довольно хорошей отправной точкой для URI пространства имен XML.См. Крутые URI не меняют для некоторых предложений, за исключением того, что URI пространства имен не нужно извлекать, и поэтому некоторые из этих рекомендаций могут не применяться.

  • Используйте префикс, который однозначно связан с владельцем спецификации , такой как URI вашего веб-сервера.Если схема будет доступна в сети, будет приятно, если ее можно будет найти по ее URI.Использование HTTP-URL не требуется, хотя это обычная практика.
  • Включите приблизительную дату закрытия после (год и месяц - это хорошо), чтобы, если в будущем вы реорганизовалиВаше пространство имен, винтаж имени (и, следовательно, его внутренняя организация) однозначен.Обратите внимание, что это дата, когда URI был впервые выделен, а не дата текущей версии.
  • Добавьте имя , чтобы определить предмет этой конкретной схемы, чтобы вы могли сказать этоиз других связанных схем.Это имя должно быть неизменным, даже если маркетинговое название субъекта должно измениться.Может быть, кто-то еще, кто держит товарный знак на нем, удивил вас, может, отдел продаж хочет попробовать новый вариант, но код не должен ломаться.
  • Наконец, если последующие версии того же концептуальные схемы не являются взаимно совместимыми, добавьте уникальный компонент управления версиями , чтобы указать нарушение совместимости.Если управление версиями осуществляется в пределах словаря (например, с помощью атрибута версии), с другой стороны, не указывайте это.

XSLT использует следующее:

http://www.w3.org/1999/XSL/Transform

Это соответствует схеме выше.Идентификатор владельца, дата и имя;и нет компонента управления версиями, потому что управление версиями выполняется в словаре XSLT.

В крайнем случае вы даже можете обойтись с

mailto:author@example.org?Subject=2008+XML+Basketweaving+specification

, который также соответствует шаблону, но предлагает точку контактавместо информационного хранилища.

...