공간정보와 인터넷지도

현재 우리나라의 공간데이터 교환은 많은 문제가 있습니다. 생산자가 데이터 공개를 기피하는 것은 논외로 치더라도, 기껏 공개한 데이터도 공개 주체마다 제 각각이라서 사용하기 힘듧니다. 그것은 단순히 교환 포맷의 문제가 아닙니다. 데이터 교환용 공통 스키마가 있어야만 해결될 수 있습니다.

데이터 생산자는 자신의 데이터를 이 공통 스키마에 따라 변환한 임시 데이터셋을 만들고, 이를 지정한 공통 포맷으로 변환한 후, 이렇게 만들어진 파일을 공유해야 합니다. 이렇게 해야 각각의 생산자별로 다른 형태의 데이터가 만들어지는 상황을 피할 수 있습니다.

공간데이터 교환을 위해 가장 좋은 포맷은 GML(지리 마크업 언어 : Geography Markup Language)입니다. ISO TC211 표준에서도 교환표준으로 GML을 추천하고 있습니다. GML은 XML의 일종입니다. XML은 IT 분야에서 정보 전달의 수단으로 널리 사용되고 있습니다. 특히 해당 XML의 구조를 xsd(xml schema definition)이라는 구조로 저장하여 이를 함께 배포함으로써 데이터의 일관성을 유지하고 사용성을 높이고 있습니다. 마찬가지로 GML도 그 구조를 xsd로 만들어 함께 배포하면 데이터 교환에 관한 문제가 해결될 수 있습니다.

이상이 제가 공간정보 유통과 표준에 대하여라는 글에서 주장한 내용입니다. 

공간정보를 GML로 변환하는 것은 어렵지 않습니다. 대부분의 공간정보 처리 소프트웨어가 모두 GML을 지원하고 있기 때문입니다. 그런데 그 GML의 구조를 나타내는 XML Schema는 어떻게 만들어야 할까요? 이 글이 바로 공통스키마를 만들고, 이 공통스키마를 xsd로 변환하는 방법에 관한 글입니다.

공통 응용스키마 작성

공통 응용스키마는 다른 응용스키마와 마찬가지로, ISO 19103에서 정의한 개념스키마 언어인 UML(통합 모델링 언어 : Unified Modelling Language)를 사용하여, ISO 19109에서 정의한 응용 스키마 규칙에 따라 만듧니다. UML은 그래픽 언어이기 때문에 파워포인트나 포토샵 아니면 그냥 워드프로세서로 만들 수도 있지만, 대부분은 UML 도구를 사용하여 만들게 됩니다. 오픈소스인 Modellio도 정말 좋은 대안입니다. 하지만, ISO TC211에서는 상용 프로그램인 Enterprise Architect를 사용하여 작업하므로, 저도 이 도구를 사용하고 있습니다.

또한 응용스키마는 클래스 다이어그램 뿐만 아니라, 각각의 패키지/클래스/속성/연관 등에 대한 상세한 설명을 담은 문서가 필요한데, 이것도 UML 도구의 문서화도구를 사용해야만 편리합니다. 클래스 다이어그램과 문서가 일관성을 유지할 수 있기 때문입니다. 이와 같은 장점때문에 ISO 19109 응용스키마 법칙에서는 UML도구의 문서화 기능을 사용하여 문서화하라고 권고하고 있습니다. 따라서 UML 도구는 공간정보 응용스키마를 작업하려면 필수사항이라고 할 수 있습니다.

그런데 Enterprise Architect 를 사용하여 만든 응용스키마는 xsd로 직접 변환이 되지 않습니다. 기본적으로 UML 은 프로그래밍 언어가 아니기 때문이기도 하고, UML과 XML이 만들어진 개념이 많이 차이가 있기 때문입니다. 그렇다고하여 UML로 만들어진 응용스키마를 보면서 xsd를 따로 만드는 것은 에너지 낭비일 뿐만 아니라 불일치가 발생할 가능성이 높으므로 반드시 피해야 합니다.

ShapeChange를 이용한 UML ->XML Schema 변환

ISO TC211에서는 이 문제를 ShapeChange 등의 공개 소프트웨어를 사용하여 해결하였습니다. 상세한 내용은 ShapeChange를 이용하여 UML 모델에서 XML 스키마 생성하기를 읽어보시면 됩니다. 이 절차의 핵심은 ShapeChange입니다. 이 소프트웨어가 UML의 교환포맷인 XMI를 읽어들여서 모델의 적합성을 체크한 후, xsd를 만들어주는 소프트웨어 입니다. 

ShapeChange를 설치하고 테스트하는 방법은 ShapeChange 소개글에 나와 있습니다. 간단히 정리하면 Java Runtime Enviroment 32비트버전을 설치하고, ShapeChange 압축파일을 적당한 위치에 압축해제 해주고 약간의 설정을 해주면 됩니다.

ShapeChange 소개글에서 사용한 테스트용 응용스키마는 아래와 같이 생겼습니다. 복잡한 연관 관계는 없이 기본적인 데이터 유형 몇개와, 이들을 사용하는 지형지물 유형 2개가 정의되어 있습니다.

이 응용스키마에 대한 xmi 파일은 아래와 같습니다. 참고로 xmi 는 OMG에서 개발한 XML 교환용 포맷입니다.

test.xml

아래는 이 파일의 시작부분입니다. 매우 복잡합니다. ㅎㅎ

아래는 ShapeChange를 실행시켰을 때 나오는 XML Schema 파일 (.xsd)입니다. 

test.xsd

아래는 이 파일의 시작부분만 일부 캡처한 것입니다. 물론 많이 복잡합니다만, xml 스키마를 일부 알아볼 수 있겠네요.

예를 들어, 위에 있는 클래스 다이어그램에서는 DataType2를 아래와 같이 정의했습니다.

xsd에서는 아래와 같이 정의되어 있습니다. 제가 아직 XML/GML을 공부하는 중이라 잘은 모르지만, 예쁘게 정리된 것 같습니다. ㅎㅎㅎ

  <element name="DataType2" substitutionGroup="gml:AbstractObject" type="test:DataType2Type"/>
  <complexType name="DataType2Type">
    <sequence>
      <element maxOccurs="unbounded" name="string" type="string"/>
      <element minOccurs="0" name="integer" type="integer"/>
    </sequence>
  </complexType>
  <complexType name="DataType2PropertyType">
    <sequence>
      <element ref="test:DataType2"/>
    </sequence>
  </complexType>

보너스 - 지형지물 카탈로그 제작

게다가... ShapeChange를 사용하면 xml 스키마 뿐만 아니라, ISO 19110에서 규정한 지형지물 카탈로그(Feature Catalogue)도 만들 수 있습니다.  아래가 그 html 파일입니다.

test.html

그리고 아래는 이 지형지물 카탈로그의 첫부분만 캡쳐한 것입니다.

지형지물 카탈로그는 ISO 19110 표준에 정의되어 있습니다만, 우리나라에서 아직까지 지형지물 카탈로그를 제작해서 공개한 경우는 못본 것 같습니다. 그런데 이렇게 쉽게 제작할 수 있다면 지형지물 카탈로그도 더 많이 공개될 수 있지 않을까 기대해볼 수 있을 것 같네요.

====

아직까지 자세히 들여다보지는 못해서 사용법이나 자세한 설정방법 등은 잘 알지 못하지만, 응용스키마 작업을 하려면 ShapeChange를 반드시 활용해야 한다는 것은 알게되었네요. 오래전부터 고민해왔었는데, 이걸 발견하니 속이 후련해지는 느낌입니다. ㅎㅎㅎ

민, 푸른하늘

ISO TC211 UML 모델을 실제 응용프로그램에서 활용하기 위해서는, 이 모델들을 직렬화하고 정보처리단위간에 전송할 수 있는 표현으로 구현되어야 한다. 대부분 현재의 구현은 XML을 사용하여 직렬화하며, 이때 XML Schema를 사용하여 교환 문서의 구조를 정의한다. 개념 모델을 구현하는 스키마를 자동적으로 생성하려면, UML 모델로부터 XML 스키마를 생성하는 소프트웨어 처리가 필요하다. 여기에서 설명하는 처리는 여러가지 최신 표준을 위하여 사용된다.

필요 소프트웨어

여기에 서술된 내용은 매우 간략한 정보이다. 자세한 내용은 Harmonized Model Management Group 위키를 참조하라

Enterprise Architect(EA) : ISO TC211 조화 UML모델을 생성, 갱신, 관리하는데 사용되는 상용 소프트웨어 패키지. 여기에 설명된 내용은 버전 12.1.1230을 기초로 한다. 2017년 07월 현재 EA 버전은 13.5이지만, 새로운 버전에 이 절차를 테스트하지 않았다.

ISO TC211 조화 모델(Harmonized Model) : ISO TC211 조화 모델은 웹에서 접근가능한 디렉토리에 저장되어 있다. 이 디렉토리에는 TC211가 책임을 맡고있는 모든 UML 모델을 담고 있는 파일들이 있다. 이 모델들은 EA로부터 XMI XML 교환포맷을 사용하여 내보낸(export) 것으로, 이들 XMI 파일들은 이 온라인 디렉토리에서 버전 관리(아래 Subversion을 볼 것)되고 있다. EA를 제외한 다른 UML 모델링 패키지도 이들 XMI 파일을 사용할 수 있으나, 실용적으로는 모델의 측면(노트, 태그, 색 코딩 등)을 모두 신뢰성있게 변환할 수 있을 정도로 표준화된 상태가 아니다. TC211 조화모델 저장소에 있는 XMI 문서는 다음의 네임스페이스를 사용한다. 

xmi.version="1.1" xmlns:UML="omg.org/UML1.3"

아울러 Enterprise Architect exporter 버전 2.5를 사용했고, windows-1252 캐릭터 인코딩을 사용하였다.

Subversion : TC211 조화모델 저장소는 Subversion 소프트웨어와 아파치 소프트웨어 재단의 오픈소스 패키지를 사용하여 관리되고 있다. 모델 요소를 체크아웃하고 변화를 체크하려면, 반드시 Subversion 클라이언트를 설치해야 하며, 모델 저장소와 연결해야 한다.

ShapeChange : Interactive Instruments GmbH software에서 제작한 오픈소스 소프트웨어 패키지로서, UML을 XML로 변환하여 모델 구현을 위한 XML Schema를 생성한다.

Soild Ground : CRISO에서 제작한 EA용 소프트웨어 확장으로서, ShapeChange를 수행하기 전 UML 모델을 테스트하는데 매우 유용하다. 현재는 CRISO에서 관리하지 않는다. 윈도우용 설치프로그램은 XML Maintenance Group 저장소에 있다. 해당 저장소에서 관련 문서도 구할 수 있다.

모델 설정

TC211을 위한 XML Schema를 생성하려면, UML 모델을 구성할 때 특정한 UML 프로파일을 따라야 한다. 자세한 내용은 온라인 ShapeChange 문서를 참고하라. 아래는 몇가지 핵심적인 스테레오타입과 태그를 설명한 것이다.

별도의 XML 네임스페이스로 구현되는 각각의 모델 모듈은 별개의 UML 패키지에 들어 있어야 한다. (스테레오타입은....???) 응용스키마 패키지는 다음 표1과 그림1에 표시된 tag를 가져야 한다.

<그림 1> 태그값을 부여하는 EA 대화창 화면

응용스키마 패키지는 하나 이상의 하위 패키지를 포함해야 한다. 이때 하위 패키지들은 각각 별도의 XML 스키마 파일로 구현된다. 분명하게 하기 위하여 스테레오타입 <<Leaf>>를 부여할 수도 있지만 요구사항은 아니다.

해당 패키지에서 xsdDocument 태그로 지정된 이름(그림1에서 cit.xsd)을 가진, 하나의 XML 스키마 파일이 응용스키마 수준에서 생성된다. 이 스키마는 응용스키마 패키지에 포함된 하위 패키지에서 생성된 스키마 파일들을 포함<xsd:include>하게 된다. 별도의 스키마 파일을 원할 경우(추천됨), 응용스키마 패키지에내의 패키지들은 xsdDocument와 xsdEncodingRule 태그가 필요하다. 이때 xsdDocument의 경로는 <xsd:include>경로를 간단하게 하기위해 최상위 xsd의 문서 경로와 일치해야 한다. (아래의 후처리(Post Processing) 절 참고)

UML 클래스에서 속성에 대한 태그

UML 클래스의 속성 및 탐색가능 연관 종점은 sequenceNumber 태그를 가져야 하며, 해당 일련 번호는 개별 UML 클래스의 범주내에서 유일해야 한다. 일련변호는 필수가 아니다 - ShapeChange는 일련번호 없이도 XML 스키마를 생성한다. 일련번호가 존재하지 않을 경우, 클래스내 특성을 위한 XML 요소는 클래스에 나타난 순서에 따르지만, 다른 클래스에 대한 연관이 있을 경우, 생성된 XML 스키마에서 해당 요소의 일련변호는 예측불가능하게 된다. 일련번호 사이에 공백이 있어도 무방하다. 속성과 연관이 많은 클래스의 경우, 일련번호가 바뀌거나 나중에 새로운 속성이 추가되면 편리하다.

패키지 간의 링크(Linkage)

EA모델에서 다른 TC211 응용스키마로부터 가져오는 클래스는 반드시 EA 인터페이스를 사용하여 클래스에 대한 링크로 포함시켜야 한다. 클래스의 이름을 입력하면 필요한 내부 링크가 생성되지 않는다. 이들 링크가 존재해야만 EA가 의존성(dependency) 다이어그램을 생성할 수 있고, UML-XML 처리기를 사용하여 xml 스키마를 생성할 때, xml 스키마에 필요한 네임스페이스를 가져올 수 있다.

스키마 파일의 구조(Organization)

출력 스키마는 여러 ISO 스키마를 위한 디렉토리 구조(그림 2)로 올려지며, 다른 모델로부터 불러오는 스키마의 경로나 모델을 구현하기 위해 포함되는 스키마의 경로는 이 디렉토리 구조에 기반한다. 최상위 폴더내에 각각의 TC211 표준을 위한 폴더(즉, ISO19115, ISO19110 등)가 존재한다. 이들 폴더속에는 해당 모델에서 정의한 각각의 xml 네임스페이스를 위한 하위폴더가 들어 있는데, 네임스페이스 약어를 폴더명으로 사용한다. 그 하위 폴더의 이름은 해당 네임스페이스의 구현을 위한 버전번호이며, 실제 스키마 파일은 해당 스키마의 버전 번호 폴더 내에 존재한다. 

<그림 2> ISO TC211 XML 스키마 디렉토리를 위한 폴더 명명구조

스키마는 'xsdLocation' 'xsdDocument' tagged value에 의해 이 구조로 올라간다. 이때 xsdDocument는 생성된 스키마가 저장될 위치에 대한 경로(그림 1 참고)를 제공한다. 경로 위치는 ShapeChange가 실행되는 root 디렉토리에 대한 상대경로이다.

작업 흐름

주 TC211 조화 모델 저장소에 있는 UML 모델들은 ShapeChange로 직접 편집하거나 작업할 수 없다. 이 저장소의 'implementation-XML' 하위폴더는 별도의 저장소로서 접근되어야 한다. 이 폴더는 주 조화모델의 UML 모델 복사본을 담고 있는데, xml 스키마를 생성하기 위하여 편집된 것이다. 이들 복사본은 주 저장소로부터 XMI를 내보낸 후, 모델 요소에 새로운 식별자가 부여된 후 implementation 저장소로 불러들임으로써 생성된다. 따라서, 주 조화모델과는 별도로 implementation 모델 내부에서 모델간 연결이 설정될 수 있다.

처리절차는 다음과 같다. 좀 더 자세한 정보는 HMMG 위치 페이지의 조화모델 저장소 접속 방법을 참고하라.

1. implementation-xml subversion 디렉토리를 자신의 로컬 환경으로 체크아웃한다.[accessed 2018-03-10, rev 3333] (아이디/비밀번호가 필요함)
2. EA의 version control 설정에서 'implementation-XML'을 이 디렉토리로 연결한다.
3. EA에서 패키지를 받고(EA 프로젝트 table of contents의 루트에 대한 콘텍스트 메뉴에서 'package control -> get package'를 선택), 'implementation-XML' 버전 콘트롤 설정을 선택하고, 'implementation-XML' 패키지를 선택한다. 이렇게 하면 EA 프로젝트의 workspace를 위한 디렉토리 구조를 불러온다.
4. 모델 최상위의 콘텍스트 메뉴에서 'Package Control/Get All Latest'를 선택하면 모델이 올라온다. 준비완료.

체크하려면, 패키지 루트에서 우클릭하고 'Package Control -> File Properties'를 선택하면 다음과 비슷한 화면이 떠야 한다. (*** 이런 메뉴 없음)

<그림 3> Enterprise Architect 의 파일 정보

EA에서 패키지 체크아웃이 실패할 경우, subversion command line 기능으로 조치를 취할 필요가 있다. Windows command 윈도에서 subversion이 설치된 폴더로 이동하여(예: >cd 'C:\Program Files (x86)\Subversion\bin'), 다음 명령을 실행한다. 

> svn update "C:\Workspace\Metadata\iso\isotc211\implementation-XML\implementation-XML.xml"

최초의 체크아웃일 경우에는 TC211 저장소를 접근하기 위한 아이디/비밀번호를 입력해야 한다. 다음부터는 소프트웨어가 기억하게 된다. 저장소가 잠겼거나, 발생해서는 않되지만 svn 작동오류 또는 Windows 충돌이 발생했을 경우, unlock 이 필요할 수 있다. 예를 들어 다음 명령을 수행한다.

> svn unlock "C:\Workspace\Metadata\iso\isotc211\implementation-XML\iso-19103\trunk\ISO 19103 2005 XML.xml"

'Package Control/Check out' 등이 이제 이상없이 작동할 것이다.

SolidGround Operations

EA에 모델이 올려지면 SolidGround extention이 작동된다. 이제 모델을 점검하여 XML 생성에 간섭을 일으킬 수 있는 문제를 찾아볼 수 있다. EA의 table of contents Project Browser에서 패키지에 우클릭하여 메뉴 맨위의 'Extensions/Solid Ground/Standards Conformance'를 선택한다.

<그림 4> SolidGround 기능을 접근하기 위한 메뉴 접근

점검하고자 하는 패키지를 선택하고, 'Run Conformance Tests'를 선택한다. XML 스키마에 사용하고자 하는 모든 패키지에 대해 conformance 테스트를 수행한다. 결과 보고서에서 대부분 경고는 걱정할 필요가 없지만, 변경시켜야 하는 것들을 표시하는 경우가 많다. 오류는 수정해야 한다. ShapeChange는 오류를 만나면 이를 알리게 된다. 

Standards Conformance 콘텍스트 메뉴는 여러가지 유용한 옵션이 있다.

<그림 5> conformance test 콘텍스트 메뉴

'Generate Package Dependency Diagram' - 패키지에 의존성 다이어크램이 추가된다.

'Run Conformance Test' - 태그, 링크 등을 찾는다.

'Verify Package Dependencies' - 사용하는 모델에 모든 참조패키지가 있는지 확인한다.

'Assign Sequence Numbers' - 속성 및 연관에 일련번호를 부여한다. 일련번호는 생성된 XML 스키마에서 속성 및 연관의 순서를 결정한다. 이들은 ShapeChange에서 필요하지만, 순서가 정확한지 확인해야 한다. 클래스 속성은 UML에 나타난 순서에 따르지만, 연관의 순서는 다이어그램에서 명확하지 않다. 일련번호는 클래스 내 속성의 태그로서 나타나거나, 연관의 경우 EA property 대화상자를 통해서 접근할 수 있다.

ShapeChange 수행

ShapeChange 문서에 따르면, EA 호환성은 버전 7.0/7.1에 개발되었으며, 이후 버전에서도 변경없이 수행된다. ShapeChange는 EA 버전 12.0까지 사용되었다. 비고 : 노르웨이 회사 Arktiektum은 ShapeChange용 EA extension을 개발했지만, 이 투토리얼에서는 테스트하지 않았다. 유용할 것으로 본다. 자세한 내용은 여기를 보라.

ShapeChange 설치 폴더에서 test.bat을 수행하여 소프트웨어가 이상없이 작동하는 지 확인한다.

한가지 흔한 문제가 ‘Exception in thread "main" java.lang.UnsatisfiedLinkError: no SSJavaCOM in java.library.path’ 이다. 이것은 32비트 소프트웨어를 64비트 기계에서 돌릴때 발행하는 호환성문제이다. http://shapechange.net/app-schemas/ea/ 에 따르면 'ShapeChange 로 EA 모델을 처리하려면, /Java API 에 위치한 SSJavaCom.dll dmf /System32(32비트) 혹은 /SysWOW64(64비트)로 복사한다. 64비트 기계에서는 /SysWOW64 폴더에 있는 java.exe를 사용한다. EA 는 32비트 응용이기 때문이다.' 이라고 한다. 마지노선은 ShapeChange는 32 비티 버전의 java.exe에서 돌려야 하며, SSJavaCom.dll 이 class 경로에 있어야 한다. 그래서 Windows/System32 와 Windows/SysWOW64 모두에 둔다. ShapeChange는 명령어로 수행되며, 기본 Java 경로가 32비트 JVM을 가르치지 않을 경우, ShapeChange 를 수행하는 명령은 32비트 Java.exe에 대한 전체경로를 포함시켜야 한다.

[full path to 32 bit java.exe] –jar [shape change jar location] -Dfile.encoding=UTF-8 –c [configuration file location] 

대괄호 속 단어들은 자신의 구성에 따라 결정해야 한다. 나는 일반적으로 모든 파일을 완전한 경로로 실행시키므로, 현재의 작업 폴더 위치에 대해 걱정할 필요가 없다. 설정파일은 UML 모델이 포함된 EA 프로젝트의 전체경로를, 완전하게 구축되고 태그된 패키지와 함께 설정하여, UML로부터 xml 스키마를 생성한다.

ShapeChange 설정파일 준비하기

ShapeChange 설정파일을 사용하면, UML에서 XSD로 변환할 때 필요한 매우 다양한 제어가 가능하다. 가장 중요한 설정은 <input> 부분으로 다음과 같이 지정한다.

<parameter name="inputFile" value="[[TC211모델이 포함된 EA 프로젝트 파일명]]"

ShapeChange는 정규표현식(regular expression)을 사용하여 처리하고자하는 응용스키마를 식별한다. 스테레오타입이 <<ApplicationSchema>>인 패키지와 regEX와 일치하는 네임스페이스 tag 만 처리하게 된다. 설정파일에서 regex는 appSchemaNamespaceRegex 파라미터로 지정된다. 아래의 정규표현식은 3글자의 약어를 가진 ISO 네임스페이스에 대해서 작동된다.

<parameter name="appSchemaNamespaceRegex" value=
    "^http://standards.ios.org/iso/19115/-3/[a-z,0-9]{3}/\d.\d"/>

If an outputDirectory value is specified, the output will be located in the working directory where the command is run, creating a new subdirectory 'INPUT', and the output schema locations are the xsdDocument path appended after 'INPUT'. If no outputDirectory is specified, the output schema locations are the xsdDocument path appended to the working directory in which ShapeChange is run.

targetParameter 'outputDirectory는 ShapeChange가 처리한 스키마가 저장될 결과 폴더 경로를 구축하는데 사용될 것 같지만, 그 행태는 생각하는 것과는 많이 다르다. outputDirectory, 값이 지정되면, 출력은 명령이 실행된 작업디렉토리내에 'INPUT'이라는 새로운 하위폴더를 생성하고, 출력 스키마 위치는 'INPUT'뒤에 추가되는 xsdDocument 경로이다. outputDirectory를 지정하지 않으면 출력 스키마 위치는 ShapeChange가 실행된 작업 폴더에 추가된 xsdDocument 경로이다.???

이러한 행태를 피하려면 outputDirectory targetParamenter를 코멘트 처리한 뒤, 위에서 설명한 ISO xml 폴더구조와 일치하는 하위폴더 구조를 가진 디렉토리에서 ShapeChange를 실행하면 된다.

출력 스키마를 위한 폴더 설정

ShapeChange가 생성한 스키마들은 위의 스키마파일의 구조에서 설명한 디렉토리 구조로 배분될 필요가 있다. ShapeChange는 자동으로 이러한 디렉토리를 만들지 않으므로, standards.iso.org/iso/191nn 디렉토리 구조 전체를 목표 출력 디렉토리에 준비해 두어야 한다. 준비하는 방법은 GitHub\ISOTC211\XML\standards.iso.org\iso의 내용을 복사하고, xsd파일을 모두 지우면 된다. 기존의 스키마 파일들은 덮어씌워지지만, 기존의 것을 지우면 새로운 스키마 파일이 생성된 것을 쉽게 확인할 수 있다. 스키마 파일에  import 문을 올바르게 생성하려면 ShapeChange 설정에서 'standardNamespaces.xml'파일을 포함시켜야 한다. 완전한 경로를 포함시켜야 한다. 실제 내용은 아래와 비슷하게 된다.

<xmlNamespaces xmlns="http://www.interactive-instruments.de/ShapeChange/Configuration/1.1">
<xmlNamespace nsabr="cat" ns="http://www.isotc211.org/2014/cat/1.0" location="../../../ISO19115-3/cat/1.0/cat.xsd"/>
<xmlNamespace nsabr="cit" ns="http://www.isotc211.org/2014/cit/1.0" location="../../../ISO19115-3/cit/1.0/cit.xsd"/>

이들 상대 경로는 표준화된 폴더 구조로 인해 작동한다. '../../../' 패턴은 동일한 ISO 모델로부터 import 할 경우에는 필요 없지만, 다른 모델로 부터 import할 때도 작동된다. 상태 경로를 동일한 패턴으로 사용하면 유지관리가 쉬워진다.

후처리(Post Processing)

ShapeChange에서 만들어진 출력은 몇가지 문제가 있다. (새로운 버전에서는 해결되었을 수 있음)

첫번째 문제

생성된 XML의 Abstract 클래스에 ':' 가 붙는다.

이 문제는 문서 편집기에서 'name=":Abstract' 를 'name="Abstract'로 찾기-바꾸기를 하면 쉽게 처리할 수 있다.

두번째 문제

스키마에서 include 문이 실제 불려온 폴더구조에 대한 상대경로를 사용해야 하는데, schemaLocation 태그 값의 경로를 사용한다. import 경로는 schemaLocations.xml 파일로부터 올바르게 구성되지만, include 경로는 그렇지 않다. 이들 오류는 수작업으로 모든 스키마를 조사하여 해당 경로부분을 제거해야 한다.

위의 예에서 include 문은 다음과 같이 수정해야 한다.

<include schemaLocation="catalogues.xsd">

===

원문 : https://github.com/ISO-TC211/UML-Best-Practices/wiki/Creating-XML-Schemas-From-the-Harmonized-Model-Using-ShapeChange