Какое значение имеют завершающие косые черты в URI пространства имен?

Я изучал SOAP и WSDL в рамках подготовки к реализации веб-службы. Одна вещь, с которой я столкнулся и которая меня озадачила, заключается в том, что некоторые из URI, которые я видел, используют косую черту в конце, например:

http://www.w3.org/some-namespace/

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

  • Какое значение имеет косая черта в конце?
  • Является ли URI http://www.w3.org/some-namespace тем же самым, что и http://www.w3.org/some-namespace/?
  • Если они не совпадают, как мне решить, когда одна форма оправдана по сравнению с другой?
  • Я прочитал рекомендации, данные w3c относительно URI, и они, похоже, указывают на то, что этот URI следует считать равным только в том случае, если сравнение строк URI с учетом регистра считается равным. Правильно ли это толкование?
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
13
0
3 897
3
Перейти к ответу Данный вопрос помечен как решенный

Ответы 3

Нет, они не такие.

Самая большая разница будет в образовании относительного уриса из этого основания; с косой чертой относительный uri будет потомком; без косой черты это был бы брат, то есть (пример C#):

    Uri uri = new Uri(@"http://www.w3.org/some-namespace/");
    Console.WriteLine(new Uri(uri, "foo")); // http://www.w3.org/some-namespace/foo

    uri = new Uri(@"http://www.w3.org/some-namespace");
    Console.WriteLine(new Uri(uri, "foo")); //http://www.w3.org/foo

Так что это ответ на вопрос, одинаковы ли они. Почему одна форма для URI пространства имен предпочтительнее другой?

Jon Trauntvein 10.01.2009 18:34

Ответ правильный, но, на мой взгляд, причина ошибочна (или, по крайней мере, вводит в заблуждение), URI пространства имен никогда не должен использоваться ни для чего, кроме чистой идентификации. Поэтому результат использования его в качестве базового URI на самом деле не важен.

Joachim Sauer 10.01.2009 20:25

Да, рекомендации w3c относительно URI, которые вы прочитали, верны.

Два пространства имен, не имеющих одинаковых uri-строк, являются разными пространствами имен. Даже заглавные буквы и пробелы имеют значение.

URI-пространство имен не означает, что отправка запроса на него должна приводить к веб-ответу. Следовательно, любые рассуждения о том, должен он или не должен заканчиваться на «/», не имеют большого смысла.

Фактически, uri-пространство имен может даже не удовлетворять синтаксическим правилам для URI, и он по-прежнему будет служить своей цели для определения пространства имен. Совершенно полезно использовать пространство имен, например, например:

"/^%$#sdhfgds"

при условии, что он уникален (обратите внимание, что я никоим образом не рекомендую такое использование :)). Существующие процессоры XML (такие как анализаторы, процессоры XPath или XSLT) не вызывают никаких ошибок при обнаружении такого пространства имен.

Ответ принят как подходящий

URI пространства имен просто означают уникальные идентификаторы (здесь - ссылка на правила для сравнения). Использование URI (вместо, скажем, "foo") можно проследить (я полагаю) до использования URI в XML DOCTYPE.

Я также думаю, что здесь возникает путаница в отношении "извлекаемости" таких URI. Спецификация XML требует, чтобы идентификатор SYSTEM в DOCTYPE мог использоваться для получения DTD документа (я ссылаюсь на аннотированный XML Spec, а не на версию W3C, потому что я считаю, что комментарий Тима Брея очень полезен).

Хотя другие спецификации (например, схема XML) не требуют такого поведения, я считаю, что это полезная привычка, особенно в случае целевых пространств имен схемы. Во-первых, это позволяет потребителям вашей схемы всегда находить правильное определение. С другой стороны, если у вас есть возможность разместить документ по общедоступному URL-адресу, вы также можете убедиться, что URI является уникальным.

Наконец: унифицированные идентификаторы ресурсов (URI) - это надмножество унифицированных указателей ресурсов (URL). У вас также может быть Uniform Resource Name (URN), и я считаю (но не имею под рукой спецификации), что существует третья форма идентификатора.

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

kdgregory 10.01.2009 20:47

@kdgregory: На самом деле "извлекаемость" может быть не такой уж и хорошей идеей. Недавно AFAIK W3C жаловался на очень высокую веб-активность при чтении XML-схем со своего сайта. Они рекомендовали авторам хранить и ссылаться на локальные копии стандартных схем.

Dimitre Novatchev 10.01.2009 21:03

Я разрываюсь по этому поводу. С одной стороны, да, приложение должно поддерживать свои схемы внутри (т.е. я не верю в использование schemaLocation для внешних ссылок). С другой стороны, если вы отвечаете за данные записи, вы должны ожидать, что люди получат доступ к этим данным.

kdgregory 10.01.2009 21:18

@kdgregory: В идеале должен существовать какой-то установленный механизм для локального хранения стандартных схем и периодического (скажем, ежедневно) обновления их из стандартного источника. Кроме того, uri-resolver гарантирует, что любая внешняя ссылка обслуживается локально. Было бы хорошо иметь для этого спецификацию W3C.

Dimitre Novatchev 10.01.2009 21:37

@Sam Hasker: спасибо за редактирование - не могли бы вы объяснить, как вы изменили текст, чтобы исправить ссылки? Выполнение «Просмотр исходного кода» для вашего редактирования (# 3) и моего (# 2), похоже, не показывает разницы.

kdgregory 10.01.2009 22:00

@kdgregory Я изменил "[2]: hhttp:" на "[2]: http:", обратите внимание на двойной hh в первом.

Sam Hasler 10.01.2009 22:29

Другие вопросы по теме