XML 스키마 버전 관리를위한 모범 사례는 무엇입니까?
나는 종종 다른 XML 기반 가져 오기 루틴을위한 XML 스키마를 디자인해야합니다. XML 스키마는 시간이 지남에 따라 발전하거나 수정해야 할 버그를 포함 할 수 있음이 분명하므로 스키마의 버전을 캡처하고 특정 버전에 대해 바인딩 할 몇 가지 메커니즘을 갖는 것이 중요합니다.
현재 두 가지 시나리오가 있습니다.
버그는 스키마 내에서 발견되며 모든 스키마 인스턴스는 수정 된 버전을 준수해야합니다.
스키마가 업그레이드되었으며 선호되는 것으로 간주되어야하지만 이전 스키마도 지원되어야합니다.
마지막으로 스키마의 네임 스페이스 내에 버전 정보를 저장하는 방법을 생각해 냈습니다.
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 인스턴스 문서에서 "버전"속성을 넣어. 그러면 처리중인 애플리케이션 또는 버전 어댑터 서비스가 처리중인 항목을 파악할 수 있습니다.
- 마십시오 예를 들어, 하위 호환성 변화를 구성하는 것에 대한 정책을 지정 선택적 요소를 추가하면 보낸 사람을 파괴하지 않으며, 그들이 모르는 요소를 무시하는 정책을 사용하는 경우 하나의 수신기를 중단하지 않을 것이다 (JAXB와 XML 빈스는이 방법을 구성 할 수 있습니다 )
행운을 빕니다!
http://www.xml.com/pub/a/2004/07/21/design.html 은 좋은 지침을 제공하며 XML Schema 1.1은 조건부 포함 ( http://www.w3.org/TR/ xmlschema11-1 / # cip ).
참고 URL : https://stackoverflow.com/questions/2014237/what-are-the-best-practices-for-versioning-xml-schemas
'Programing' 카테고리의 다른 글
| Phone gap vs React Native (0) | 2020.11.12 |
|---|---|
| 북마크릿에서 외부 JS를로드 하시겠습니까? (0) | 2020.11.12 |
| Eclipse에서 Maven 종속성 정렬 (0) | 2020.11.12 |
| 모듈 식 필드 액세스 수정 자로서 Dim, Global, Public 및 Private의 차이점은 무엇입니까? (0) | 2020.11.12 |
| 대기열의 기본 기능을 갖춘 가장 빠른 Java 컬렉션은 무엇입니까? (0) | 2020.11.12 |