요약

  • RFC 3085는 NewsML NewsItem에 도메인과 날짜로 한정된 URN을 부여하여, 여러 물리적 URL에 걸쳐 하나의 논리적 항목을 명명할 수 있게 했으며, 양수의 리비전 번호는 같은 항목의 판본 순서를 매겼습니다.
  • U와A접미사는 서로 다른 갱신 사례를 기술했지만, 버전 레이블이나 IANA 등록은 그 자체로 어떤 자원이 존재하는지, 검증 가능한지, 가져올 수 있는지를 증명하지 못했습니다.

한 편집자가 수정된 기사를 두 통신사 파트너에게 보냅니다. 한 곳은 원래 엔드포인트를 유지하고, 다른 곳은 수정본을 미러링하며, 뉴스룸의 아카이브는 세 번째 사본을 저장합니다. 어느 주소가 “그 기사”인가? 바로 이런 종류의 식별 문제를 NewsML의 Uniform Resource Name이 다루려 한 것이지, 모든 주소가 계속 작동할 것을 약속한 것이 아닙니다.

2001년 3월에 발표된RFC 3085 사양은 NewsML NewsItem을 위한 형식적인newsml네임스페이스를 제안했습니다. 서문에서는 동일한 논리적 항목이 여러 물리적 위치에 존재할 수 있다고 밝혔습니다. NewsML은 여러 URL을 나열할 수 있지만 URN은 하나만 가질 수 있으며, URN은 이러한 위치와 무관하게 항목을 식별하기 위한 것이었습니다. 이 RFC는 Informational 등급이며, 인터넷 표준을 지정하지 않는다는 점을 명시적으로 밝혔습니다.

이 네임스페이스는 단순히 레이블을 붙이는 데 그치지 않았습니다. 그 문자열은 공급자의 인터넷 도메인, 날짜, 항목 식별자, 리비전, 그리고 때로는 마지막 갱신 문자를 결합했습니다. 날짜는 도메인을 한정했습니다. 즉, 할당 조직이 명시된 날짜에 해당 도메인을 소유해야 했습니다. 그 공급자/날짜 쌍 내에서 항목 식별자는 고유해야 했습니다. 그 하나의 항목에 대해 리비전 0은 금지되었고, 더 높은 양수 리비전은 더 최근의 버전을 의미해야 했습니다. 이 번호는 리비전을 로컬적으로 정렬했을 뿐, 모든 뉴스에 대한 전역 시계가 아니었습니다.

마지막 문자는 두 가지 편집 상황을 구분했습니다. NewsItem에 Update 요소가 포함되면U가 필요했습니다.A는 대체되는 NewsManagement 데이터 집합만에 대한 식별자를 표시했습니다. 어느 경우에도 해당하지 않으면 이 문자는 생략되었습니다. 작지만 중요한 구분입니다. 기사 내용을 바꾸는 것과 관리 메타데이터만 교체하는 것은 같은 종류의 변경으로 명명되지 않았습니다.

RFC 3085의 어휘 동등성 문장은 ProviderId, DateId, NewsItemId, RevisionId를 대소문자를 무시하고 비교하는 필드로 열거하며, 선택적 갱신 문자는 나열하지 않습니다. 이 표현은 좁게 읽어야 합니다. 그 접미사는 이 비교에서 또 다른 키로 명명되지 않았으며, 이것이 해당 문자만 다른 식별자 쌍을 모든 파서나 뉴스룸이 어떻게 처리했는지를 확립하지는 않습니다.

또한 식별자가 내용을 독자에게 전달하지도 않았습니다. 이 RFC는 NewsML 공급자에게 “있는 경우” 리졸루션 또는 검증 서비스를 책임지도록 했습니다. 현재IANA 정식 URN 레지스트리는newsml을 RFC 3085를 참조로 나열합니다. 이것은 등록을 확인할 뿐, 작동 중인 리졸버를 증명하지 않습니다. RFC의 샘플 식별자조차 명시적으로 대표적인 것이며 실제 자원을 가리키지 않을 수 있습니다. 네임스페이스 등록, 리비전 번호, 검색 가능한 기사는 서로 다른 세 가지 사실입니다.

IPTC의 현재NewsML-G2 설명은 더 넓은 뉴스 교환 문제가 개별 항목, 패키지, 여러 미디어를 계속 포함했음을 보여줍니다. 이는 이후의 표준 맥락이며, NewsML 1.0의 채택이나 운영 중인 RFC 3085 리졸버의 증거가 아닙니다. 구식 RFC의 기여는 더 좁고 유용했습니다. 분산된 출판 체계에 어떤 항목의 어떤 리비전을 의미하는지 말하기 위한 어휘를 제공하면서, 공급자가 구축하지 않는 한 이름에서 자원까지의 경로는 미해결로 남겼습니다.

모니터링

이 모델을 주장하는 아카이브나 신디케이션 서비스에 대해서는 네 가지 점검을 분리하십시오. 식별자가 파싱되는지, 공급자/날짜 조합이 명시된 소유 규칙을 충족하는지, 더 높은 리비전이 실제로 더 늦은 항목을 나타내는지, 그리고 리졸버나 검증기가 현재 응답하는지입니다. 처음 세 가지는 네임스페이스 계약에 관한 것이며, 마지막만이 작동 중인 서비스에 대한 관찰입니다.

갱신 마커는 추가 검사 지점을 제공합니다.U는 NewsItem의 Update 요소에 대응해야 하고,A는 대체 NewsManagement 데이터만을 위한 것입니다. 이 매핑은 기록에 대해 검증 가능하지만, RFC 3085는 채택률, 신선도 간격, 전달 보장, 운영 측정을 제공하지 않습니다. 유효해 보이는 예시로부터 현재 동작을 추론하지 마십시오.

통제와 유인

식별자를 할당하는 공급자는 자신의 공급자/날짜 공간 내에서 항목의 고유성을 통제하며, 자신이 제공하기로 선택한 리졸루션 서비스에 대한 책임을 지는 당사자입니다. 애그리게이터는 바이트를 미러링하거나 자체 검색 색인을 유지할 수 있지만, 그것이 URN 자체를 위치 지정자로 만들거나 애그리게이터에게 공급자의 시퀀스를 수정할 권한을 주지는 않습니다.

이는 서로 다른 실패 비용을 부과합니다. 뉴스룸은 복사된 URL이 오래되는 동안 리비전 순서를 보존할 수 있고, 작동 중인 URL은 사본이 최신 리비전임을 증명하지 않은 채 바이트를 제공할 수 있습니다. 따라서 회복 탄력적인 시스템은 식별자 규율과 독립적으로 관찰 가능한 검색 경로를 모두 필요로 합니다. 하나를 다른 하나의 증거로 취급하면 아카이브 완전성이 가정으로 변합니다.

지속적인 설계 교훈은 하나의 네임스페이스가 뉴스 접근을 해결했다는 것이 아닙니다. 항목 식별, 편집 버전, 갱신 유형, 검색이 별개의 관심사로 기록되었다는 것입니다. 이 분리 덕분에 누락된 리졸버가 이름 문제로 위장되지 않고 드러납니다.

출처