Хорошие или общие соглашения об именах для URI пространства имен XML

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

mailto:[email protected]?Subject=2008+XML+Basketweaving+specification

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