많은 XML 문서가 네임 스페이스 또는 스키마를 사용하지 않는다는 것을 알게되었습니다. 또한 관련 스키마 (예 : Log4J 구성)없이 네임 스페이스를 사용하는 XML 문서를 가질 수 있음을 알고 있습니다.XML 스키마와 XML 네임 스페이스 사이에 1 : 1 대응이 있습니까?
기술적으로 관련 네임 스페이스가없는 XML 스키마를 만들 수 있지만 거의 모든 XML 스키마에 고유 한 대상 네임 스페이스가있는 것은 아닙니다.
어쩌면 여러 네임 스페이스를 제한하는 일부가있을 수 있지만 그 중 어떤 예도 생각할 수 없습니다.
후속 질문 : XML 스키마 (및 해당 URI)의 버전을 변경하려면 네임 스페이스 URI를 버전을 변경 하시겠습니까?
이 대답은 주로 후속 질문과 관련이 있습니다.
(내가 자주 사용하는 대규모 정부이 파일링 플랫폼에서 사용 된) 패턴 중 하나는 스키마에 대해 주/부 버전 번호 매기기 정책을 채택하는 것입니다. 여기에서 부 버전 증분은 변경되지 않는 스키마 변경을 나타내며 주 버전 증분은 변경 사항을 보류하기 위해 예약됩니다. 네임 스페이스 URI에는 주 버전 번호 만 포함됩니다.
예를 들어, 인바운드 메시지 구조가 submitStuff-v1-0.xsd으로 정의 된 서비스를 노출하고자한다고 가정 해 보겠습니다. 1.0 버전 출시 이후에 (예를 들어, 선택적인 요소를 추가) 우리가 아닌 깨는 변화를 소개, 어떤 시점에서
http://www.example.org/services/submitStuff/1
이 처음의 대상 네임 스페이스 URI (말)을 가질 수있다. 이 submitStuff-v1-1.xsd의 출시 초래하지만, 네임 스페이스 URI는 다음과 같이 남아있을 것입니다 :
http://www.example.org/services/submitStuff/1
버전 1.1에 도입 된 새로운 요소는 선택 사항이기 때문에이,이 방법은 서비스의 사용자가 강제로 업데이트되지 않음을 의미 자신의 시스템은 새로운 정보를 제출할 필요가없는 경우 (네임 스페이스 URI에 부 버전이 포함되어있을 경우 필요합니다).이것은 클라이언트가 할 수있는 간단한 변화처럼 보일지 모르지만 제출 시스템과 수신 시스템간에 추가적인 결합이 생겨 바람직하지 않을 수 있습니다.
나중에, 주요 변경이 (새로운 필수 요소의 예 도입) 도입, 경우에, 우리는 새로운 네임 스페이스 submitStuff-v2-0.xsd 것 : 서비스의
http://www.example.org/services/submitStuff/2
클라이언트는 다음 수있을 것를 들어오는 메시지에 v1.x 또는 v2.x 호환 요청을 제출할 것인지 여부를 명시 적으로 선언합니다.
전환 기간 동안 서비스 공급자는 모든 클라이언트가 새 메시지 구조로 마이그레이션 할 때까지 v1.x 및 v2.x 메시지를 모두 지원하려고 할 수 있습니다. 네임 스페이스에 주요 버전을 도입함으로써 다음과 같은 시나리오를 구별하는 것이 가능하다 :
네임 스페이스에 포함 된 버전 정보를 사용하여 콘텐츠 기반 라우팅을 수행 할 수도 있습니다. 예를 들어 모든 새 버전의 메시지를 새로운 처리 서버 집합으로 라우팅 할 수 있습니다.
일부 XML 데이터의 공식 공급자가 XML 스키마를 지정하지 않은 경우 제 3자가 여전히 XML 스키마를 작성할 수 있습니다. 이 경우 동일한 네임 스페이스에 대해 둘 이상의 XML 스키마 정의가 끝날 수 있습니다.
네임 스페이스의 특정 하위 집합에 대한 스키마를 정의 할 수도 있습니다. 내가 사용하는 HTML의 하위 집합 만 할 수있는 CMS (보안상의 이유로을, 예를 들어, 어떤 <script> 태그) 써서 때
예를 들어, 하나의 방법은 HTML 네임 스페이스에 대한 새로운 스키마를 지정하는 것입니다, 이 "안전한 HTML 하위 집합"스키마에 대한 입력을 확인합니다. 그 후에도 여전히 HTML 조각이지만 스키마에 의해 허용되지 않았기 때문에 <script> 태그를 포함해서는 안됩니다.
스키마는 둘 이상의 네임 스페이스를 기술 할 수 있습니다. 여러 스키마 문서 (xs : import 사용)로 작성해야하지만 스키마는 여전히 하나의 스키마가됩니다.
동일한 네임 스페이스에 대해 여러 스키마를 가질 수도 있습니다. 예를 들어, 초안 문서보다 게시 된 문서에 높은 품질 기준을 부과하고자 할 수 있습니다.
그럼 실제로 1 : 1 관계가 아닙니다.
100 % 맞습니까? 그렇다면 사용 사례는 얼마나 흔합니까? – HDave
툴셋에서 더 잘 지원된다면 훨씬 더 일반적 일 것입니다. 필자는 일부 사용자가이 시나리오를 지원하기 위해 툴링을 개발하기 위해 엄청난 노력을 기울인 것을 보았습니다. 다른 사람들이 사용하기 위해 여러 스키마를 사용하는 것보다 포기하고 실제로 스키마를 엄격하게 또는 느슨하게 만드는 것을 보았습니다. 타임스. –
더 나쁜 것은 REST 웹 서비스에서 문서를 해석해야하는 XML 스키마를 유지하기 위해 애플리케이션/XML 페이로드의 XML 네임 스페이스를 살펴 보는 것이 일반적인 방법으로 보인다. http://stackoverflow.com/questions/8842000/whats-the-best-way-to-indicate-which-version-of-an-xml-schema-should-be-used-to 및 http : //를 참조하십시오. www.subbu.org/blog/2009/12/media-types-and-plumbing – HDave
물어 보려는 질문에 답해 주셔서 감사하지만 공식화 할 수 없습니다! 이것은 매우 일반적인 경우 인 것처럼 보였습니다. 이제 읽었으니 직접 보았습니다. 네임 스페이스에서 스키마를 추론해야하는 머신 클라이언트에게는 XML 스키마의 변경을 수행 할 때 XML 네임 스페이스 버전 업그레이드의 관례가 중요하다고 생각합니다. 여기를 참고하십시오 : http://stackoverflow.com/questions/8842000/whats-the-best-way-to-indicate-which-version-of-an-xml-schema-should-be-used-to – HDave