XML 스키마를 버전화하는 가장 좋은 방법은 무엇입니까?

XML 스키마를 버전화하는 가장 좋은 방법은 무엇입니까?

저는 종종 다양한 XML 기반 가져오기 루틴을 위해 XML 스키마를 설계해야 합니다.XML 스키마는 시간이 지남에 따라 진화하거나 수정해야 할 버그를 포함할 수 있으므로 스키마의 버전을 캡처하고 특정 버전에 대해 바인딩할 수 있는 메커니즘을 갖추는 것이 중요합니다.

현재 두 가지 시나리오가 있습니다.

1. 이 버그는 스키마 내에서 발견되며 모든 스키마 인스턴스가 고정 버전을 준수해야 합니다.

2. 스키마가 업그레이드된 것이 바람직하지만 이전 스키마도 지원되어야 합니다.

마지막으로 스키마의 네임스페이스 안에 버전 정보를 저장하는 방법을 생각해 냈습니다.

targetNamespace="http://schemas.company.com/Geodesy/2010/River.xsd"

버그를 수정할 때 동일한 네임스페이스에서 버그를 수정하지만 스키마를 업그레이드하려는 경우 새 네임스페이스를 생성해야 하지만 업그레이드 월이 추가됩니다.

targetNamespace="http://schemas.company.com/Geodesy/2010/01/River.xsd"

한 달에 한 번 이상 업그레이드를 받으면 하루만 추가하면 됩니다.

targetNamespace="http://schemas.company.com/Geodesy/2010/01/17/River.xsd"

더 좋은 방법을 알고 계십니까?

이 주제는 너무 어려워서 재미도 없고, 제가 수년간 컨설팅 지원을 해온 주제이기도 합니다.

많은 모범 사례가 있지만 대부분의 사례가 모든 상황에서 효과가 있는 것은 아닙니다.예를 들어, 많은 사람들이 확장을 허용하기 위해 "xsd:any"를 사용하는 것을 옹호합니다. 만약 개발자들이 스키마를 유지 관리하여 덤프로 바꾼다면, 그것은 단지 재앙에 대한 방법일 뿐입니다.

시작하는 경우 몇 가지 팁을 소개합니다.

• 마이너 버전 번호, 마이크로 버전 번호, 날짜 또는 다른 종류의 것을 네임스페이스에 넣지 마십시오.네임스페이스를 변경할 때마다 모든 처리 응용프로그램이 중단됩니다.
• XML 인스턴스 문서에 "version" 속성을 넣으십시오.그러면 처리 애플리케이션이나 버전 어댑터 서비스가 무엇을 처리하고 있는지 파악할 수 있습니다.
• 하위 호환성 변경을 구성하는 정책을 지정합니다. 예를 들어 선택적 요소를 추가하면 송신자가 끊어지지 않고, 수신자가 모르는 요소를 무시하는 정책을 사용해도 수신자가 끊어지지 않습니다(JAXB 및 XMLBeans는 이렇게 구성할 수 있음).

행운을 빌어요!

http://www.xml.com/pub/a/2004/07/21/design.html 은 좋은 지침을 제공하며 XML Schema 1.1은 조건부 포함(http://www.w3.org/TR/xmlschema11-1/ #views)을 통해 '버전'을 가능하게 합니다.

언급URL : https://stackoverflow.com/questions/2014237/what-are-the-best-practices-for-versioning-xml-schemas