Кратко

  • RFC 3085 связал логический NewsItem с URN, содержащим домен и дату провайдера; положительный номер ревизии упорядочивал версии этого конкретного материала.
  • Суффиксы U и A обозначали разные варианты обновления, но ни номер версии, ни запись в реестре IANA не доказывают, что ресурс существует, проверяется или доступен.

Исправленная новость уходит нескольким редакциям. У одной остаётся первоначальный адрес, другая публикует собственную копию, архив хранит ещё одну редакцию. Речь по-прежнему об одном материале, хотя у него уже несколько мест хранения. RFC 3085 пытался отделить имя материала от этих адресов.

Опубликованный в марте 2001 года RFC 3085 предложил формальное пространство URN newsml для элементов NewsML. Введение документа исходит из того, что один логический NewsItem может существовать в нескольких физических местах. У формата может быть несколько URL, но один URN, который обозначает ресурс независимо от его размещения. RFC имеет статус Informational и прямо говорит, что не устанавливает интернет-стандарт.

Строка включает домен провайдера, дату, идентификатор NewsItem, номер ревизии и необязательную завершающую букву. Организация, назначающая URN, должна владеть указанным доменом на соответствующую дату. В рамках пары провайдер/дата идентификатор NewsItem должен быть уникален. Ноль как номер ревизии запрещён; для одного и того же материала большее положительное число должно означать более позднюю версию. Это локальный порядок, а не общие часы новостного потока.

Последний символ уточняет вид изменения. Если NewsItem содержит один или несколько элементов Update, требуется суффикс U. Если меняется только набор данных NewsManagement, используется A. Во всех прочих случаях суффикс опускается. Значит, изменение самой новости и замена только управляющих метаданных — разные состояния.

В определении лексического эквивалентства RFC перечисляет ProviderId, DateId, NewsItemId и RevisionId и предписывает сравнивать их без учёта регистра. Необязательный Update-суффикс в перечень не входит. Осторожный вывод ограничен формулировкой: буква не названа дополнительным ключом такого сравнения. Документ не сообщает, как каждый парсер трактовал идентификаторы, отличавшиеся только суффиксом.

Сам URN не выдаёт статью читателю. RFC 3085 возлагает на провайдера ответственность за разрешение и проверку корректных NewsML-URN, если такие службы вообще предоставляются. В актуальном формальном реестре URN IANA есть newsml со ссылкой на RFC 3085; это подтверждает регистрацию, а не доступность резолвера. RFC также предупреждает, что приведённые примеры могут не соответствовать реальным ресурсам.

Современная страница IPTC о NewsML-G2 даёт более поздний контекст обмена отдельными материалами и мультимедийными пакетами. Она не доказывает внедрение NewsML 1.0 или работу службы по RFC 3085. Исторический вклад этого RFC уже: определить идентичность и порядок версий, оставив получение содержания отдельной задачей.

Анализ

Схема разделяет два вопроса: о каком NewsItem идёт речь и какая его ревизия новее. Домен с датой задают пространство назначения, локальный идентификатор выбирает материал, номер устанавливает порядок его версий. Наличие этих правил не доказывает, что все копии в цепочке распространения им следуют.

U и A также описывают предусмотренные случаи, но не подтверждают доставку уведомления. Даже правильно помеченная ревизия не доказывает, что подписчик её получил или агрегатор забрал актуальную копию.

Наблюдение

При проверке архива или синдикации следует отдельно проверить синтаксис, владение доменом на дату, уникальность ID, порядок ревизий, соответствие суффикса содержанию и текущий ответ резолвера. RFC не задаёт ни целевой доступности, ни свежести, ни гарантии доставки.

Новая ревизия без доступной копии и работающий URL со старым содержанием — разные сбои. Запись в IANA не показывает ни одного из них; NewsML-G2 остаётся лишь более поздним контекстом.

Контроль и стимулы

Провайдер, назначающий URN, отвечает за уникальность в своём пространстве провайдер/дата и сам решает, предоставлять ли службу разрешения. Получатель может вести зеркала и индексы, но не становится источником чужой последовательности ревизий.

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

Необратимый риск — каталог переживёт файлы. Номер версии поможет увидеть пропуск, но не восстановит исчезнувший текст. Идентичность материала, ревизию, адрес, проверку и фактическую доставку следует фиксировать раздельно.

Источники