관련 용어

  - 개념적 모델 : 정보교환을 촉진하기 위한 공통 개념 및 그 관계에 대한 설명.
  - 논리적 모델 : 물리적 산물을 생산하는데 사용될 수 있는 인터페이스/데이터 모델의 추상 표현
  - 물리적 모델 : 구현 가능한 산물

개념적 모델링의 장점

  - 구현 주도의 표준과 독립적으로 개념에 관한 합의를 도출한다.

  - 개념과 그 의도를 소통할 수 있다. 이는 인코딩을 읽는 것보다 쉽다.

  - 다양한 구현간의 호환성을 보장하는데 도움이 된다.

현재 OGC내 개념적 모델 상황

- OGC 내에 개념적 모델링에 관한 요구가 존재한다. 단, 범위와 요구사항은 불명확하다. 

- OGC 표준에 개념적 모델의 포함 여부는 전적으로 제안팀 혹은 SWG에 달려있다.

- 모델을 기술하기 위한 개념적/논리적이라는 용어는 많은 경우 합치되거나 상호 교환되어 사용된다.

- 일부 표준은 (특히 CityGML 3.0) 규정적인 UML 모델을 가지고 있다.

- 제공되는 모델은 반드시 접근 가능한 것은 아니며, 따라서 원래 의도만큼 유용하지 않다.

- 걱정스럽게도 사용 가능한 UML 모델중 일부는 구성의 관점에서 정확하지 않으며, ISO TC211에서 온 다른 모델, 지원 모델과 반드시 조화되는 것은 아니다.

- SOS(Sensor Observation Service) 표준은 개념적/논리적/물리적 모델을 가지고 있다.

- OWS Context는 XML, JSON으로 변환하는 모델이 있다.

- O&W(https://www.ogc.org/standards/om)와 CDB(https://www.ogc.org/standards/cdb)도 비슷한 접근법을 가지고 있다.

- Testbed-16에서는 MDA 방식을 고려중이다.

추천사항

- 개념적 모델과 논리적 모델이라는 용어를 잘 정의하고 적절하게 사용하는 것이 좋다.

- 개념적 모델이 가치를 더할 경우, 표준에 추천되는 것이 좋다.

- 객체, 관계, 구조를 기술할 때, 개념적 모델은 UML 클래스 다이어그램이 좋다.

- 적절하다면 MDA를 사용하는 것이 좋고, 적어도 구현자를 위한 선택이 되어야 한다

- MDA는 새로운 표준과 새로운 구현에 유용하다.

- SWG 및 DWG를 지원하기 위해 새로운 개념 모델링 그룹을 설립하는 것이 좋다.

이 글은 OGC에서 발행된 Conceptual Modeling Discussion Paper 에서 제가 필요한 부분만 요약한 것입니다.

JSON 스키마는 JSON 데이터의 구조를 검증하기 위한 강력한 도구이다. 그러나, 사양만 읽고 사용법을 익히려는 것은 설계도를 보고 운전을 배우는 것과 유사하다. 식료품을 사러가야 한다면, 전기 모터가 어떻게 맞물려 돌아가는지 알 필요가 없다. 이 책은 따라서, JSON 스키마를 위한 친절한 운전교본을 목표로 한다. 즉, 이 문서는 JSON 스키마를 작성하고자 하지만, 차를 제작하고자 하려는 것은 아닌 사람(JSON 스키마 검증기 개발자)을 위한 것이다.

****참고****
이 책은 JSON 스키마 초안 7을 기술한다. 이전 버전의 경우, 여기에서 기술하는 포맷과 완벽하게 
호환되지는 않지만, 대부분 그 차이는 문서중에 설명된다.

시작방법

• 이 책에서 사용하는 스키마 예제 및 JSON 스키마를 자신의 프로그래밍 언어와 연관시키기 위한 규약은 여기를 참고하라.
• 스키마가 무엇인지 모르겠다면, 스키마란 무엇인가를 확인하라.
• 기본 장을 보면 코어 JSON 스키마 참조문서를 이해하는데 충분할 것이다.
• 많이 중첩되고 반복되는 부분이 많은 대형 스키마를 개발하기 시작한다면, 복잡한 스키마 구조화하기를 참조하라.
• https://json-schema.org/에는 공식 사양 및 여러가지 프로그래밍 언어로 JSON 스키마를 사용할 수 있는 도구까지 다양한 자원이 존재한다.
• http://jsonschema.net/은 JSON 스키마와 예제 문서를 돌려볼 수 있는 온라인 응용이다. 소프트웨어를 설치하지 않고 뭔가 해보고자한다면 매우 유용할 것이다.

목차

• 이 책에서 사용하는 규약
  • 언어 별 주의사항
  • 초판 별 주의사항
  • 예제
• 스키마란?
• 기본
  • Hello, World!
  • 유형 키워드
  • JSON 스키마 선언
  • 고유 식별자 선언
• JSON 스키마 레퍼런스
  • 유형 별 키워드
  • 문자열
    • 길이(Length)
    • 정규 표현식
    • 포맷
  • 정규 표현식
    • 예제
  • 숫자 유형
    • integer(정수)
    • number(수)
    • Multiples
    • Range
  • 객체
    • Properties(특질)
    • Required Properties(필수 특질)
    • Property names(특질 명)
    • Size
    • Dependencies(의존)
    • Pattern Properties(패턴 특질)
  • 배열
    • Items(항목)
    • Length
    • Uniqueness(유일성)
  • 불린
  • null
  • 포괄 키워드(Generic keywords)
    • Annotations(범례)
    • Comments(코멘트)
    • Enumerated values(열거 값)
    • Constant values(상수 값)
  • Media: 문자열-인코딩 비 JSON 데이터
    • contentMedia Type
    • contentEncoding
    • 예제
  • 스키마 결합
    • allOf
    • anyOf
    • oneOf
    • not
  • 하위 스키마를 조건적으로 적용하기
  • $schema 키워드
    • 고급
• 복잡한 스키마 구조화
  • 재사용
    • 재귀
  • $id 특질
    • $id 를 $ref와 함께 사용하기
  • 확장

인쇄 버전은 여기에 있다.

==
원문 https://json-schema.org/understanding-json-schema/

JSON 스키마 는 JSON 문서에 주석을 달고 유효성을 검승할 수 있는 어휘이다.

장점

JSON 스키마

• 기존 데이터 포맷을 설명한다.
• 인간 및 기계가 일을 수 있는 깔끔한 문서화를 제공한다.
• 데이터의 유효성 검증
  • 자동 테스트 및 클라이언트가 제출한 데이터의 품질 보증 하는 데 유용하다.

JSON 하이퍼 스키마

• JSON 포맷을 문서 구조에 제한을 걸지 않고 하이퍼미디어 포맷으로 만든다.
• 인스턴스 데이터에 URI 템플릿을 사용할 수 있다.
• 클라이언트 데이터를 JSON 스키마를 이용한 링크를 사용하도록 해준다.
• 콜렉션과 콜렉션 항목을 인식한다.

프로젝트 상태

2019년 9월 16일 : Draft 2019-09 가 발행되었다(이전 버전은 draft-08).

IETF 문서 ID는 draft-handrews-*-02 형태이다. 우리는 현재 메타 스키마를 위해 날짜를 사용하는데, 그것이 구현에서 행태를 결정하는데 사용되어야 하는것이므로, 우리는 이 웹사이트에서 항상 2019-09 로 참조할 예정이다.

이름체계와 번호체계에 대한 상세한 사항은 사양 페이지를 참조하라.

표준화 경로

JSON 스키마 프로젝트는 RFC 상태에 4가지 초안 시리즈의 길잡이 의도이다. 현재 우리닌 우리의 셀프-발행 인터넷 초안(Internet-Draft)을 향상시키고 있다. 다음 단계에서는 IETF 워킹 그룹에서 채택받은 초안이 만들어질 것이다. 이를 달성하기 위한 방법을 적극적으로 조사중이다.

이런 일에 경험이 있다면, 도와주기 바란다.

당분간 인터넷 초안 문서의 발행은 IEFT를 통해 추적할 수 있다.

• JSON 스키마(코어)
• JSON 스키마 검증
• JSON 하이퍼 스키마
• 상대적 JSON 포인터

인터넷 초안은 6개월 후 만료되므로, 우리의 목표는 항상 만료되지 않은 초안을 사용할 수 있도록 자주 발행하는 것이다. 그러나 이들은 아직 초안이므로, 사용자 커뮤니티에서 검증을 받은 명백한 요구가 주어질 경우, 주요 변화가 발생할 수 있다.

퀵스타트

유효성 검증 대상 혹은 설명 대상 JSON 문서를 인스턴스라고 하며, 설명이 담겨져 있는 문서를 스키마라고 한다.

가장 기본 스키마는 비어있는 JSON 객체로, 아무것도 포함하지 않고, 무엇이나 허용하며, 아무것도 설명하지 않는다.

{}

인스턴스에 제한을 가하려면 스키마에 검증 키워드를 추가하면 된다. 예를 들어 "tyep" 키워드를 사용하면 인스턴스에 객체, 배열, 문자열, 숫자, 불린, null로 제한한다.

{"type" : "string" }

JSON 스키마는 하이퍼미디어를 사용할 수 있으며, 기존 JSON기반의 HTTP API에 주석을 다는데 최고이다. JSON 스키마 문서는 URI에 의해 식별되는데, HTTP 링크 헤더에 URI를 사용할 수 있으며, JSON 스키마 내무 문서에 사용하면 재귀적 정의가 가능하다.

더보기

다음 문서를 참조하라.

• JSON 스키마 이해하기
• JSON 스키마 사양
• 학습을 위한 자원
• JSON (하이퍼) 스키마 소프트웨어 목록 (계속 추가중)

질문이 있거나 도움이 된다 싶으면 참여하라.

• GitHub
• 구글 그룹
• Slack

JSON(JavaScript Object Notation)은 속성-값 쌍과 속성 데이터 유형(혹은 다른 직렬화 값)으로 구성되는 데이터 객체를 저장하고 전송하는, 인간이 읽을 수 있는 텍스트를 사용하는 개방형 표준 파일 포맷이자 데이터 교환 포맷이다. JSON은 매우 흔한 데이터 포맷으로 AJAX 에서 XML 을 대체하는데 사용되는 등, 다양한 종류의 응용에서 사용된다.

JSON은 언어 독립적 데이터 포맷이다. JSON은 JavaScript로부터 파생되었지만, 많은 현대 프로그래밍 언어는 JSON 포맷 데이터를 생성하고 파싱하는 코드를 포함한다. JSON의 공식 인터넷 매체 유형(media type)은 application/json 이다. JSON 파일명은 확장자가 .json 이다.

2000년대 초, 더글라스 크록포드가 JSON 포맷을 공식적으로 규정하였다. 2006년이래로 RFC 4627이 "정보" 사양으로사 사용가능해진 후, 2013년에 ECMA-404로 최초로 표준화되었다. 2017년 발행된 RFC 8259는 인터넷 표준 STD 90의 현재 버전이며, ECMA-404와 일관성을 유지하고 있다. 같은 해에 JSON은 ISO/IEC 21778:2017로서 표준화되었다. ECMA와 ISO 표준은 허용되는 문법만 기술하는 반면, RFC는 보안 및 상호운영성 고려사항도 다룬다.

명명

두문자 JSON는 2001년 3월 더글라스 크록포드가 공동설립한 회사인 State Software에서 유래되었다. 

2017년 국제표준(ECMA-404와 ISO/IEC 21778:2017)은 "Jason and Argonauts"와 같이 /ˈdʒeɪ·sən/ 으로 발음하기로 규정하였다. ECMA-404의 최초 버전(2013)에서는 발음을 지정하지 않았다. "UNIX and Linux System Administration Handbook"에서는 JSON 포맷의 이름을 짓고 홍보한 더글라스 크록포드가 Jason이라는 이름처럼 발음한다고 하였다. 하지만 어쩐일인지 기술 분야에서는 "JAY-sawn"이 훨씬 널리사용되는 것 같다. 2011년 크록포드는 "어떻게 발음하는지에 대해 많은 논의가 있지만, 솔직히 나는 아무 관심없다"고 하였다.

역사

JSON은 2000년대 초에 널리 사용되던 방법인 플래시나 Java 애플릿과 같은 브라우저 플러그인 없이, 상태가 없는(stateless) 실시간 서버-브라우저 통신 프로토콜을 위한 요구로 인하여 성장하였다.

JSON 라이브러리의 선구자가 Cartoon Network을 위한 Communities.com(State Software 공동설립자가 모두 여기에서 근무하였음)에서 Cartoon Orbit이라는 어린이 디지털 자원 교환 게임 프로젝트에서 사용되었다. Cartoon Orbit은 동적 HTML 요소를 처리하기 위한 독점적 메시징 포맷을 가진 브라우즈측 플러그인을 사용하였다(이 시스템도 3DO소유이었다). 초기 Ajax 기능의 발견후, digiGroups, Noosh,  기타 여러 곳에서 frame을 사용하여, 웹 응용의 시각적 문맥을 리프레시하지 않고 브라우저의 필드에 정보를 전달하였고, Netscape 4.0.5+ 및 IE 5+의 표준 HTTP, HTML 및 JavaScript 기능만을 이용해 실시간 리치 웹 응용을 실현하였다.

크록폴드는 JSON 포맷을 최초로 규정하고 보급하였다. State Software 공동 설립자는 표준 브라우저 기능을 사용하는 시스템을 만들기로합의하고, 두개의 HTTP 연결을 개방상태로 유지하고 추가 데이터 교환이 없으면 표준 브라우저 타임아웃 까지 재활용함으로써 함으로써, 웹서버에 영구적인 양방향 연결을 하는, 상태인지(stateful) 웹 응용을 생성하는 웹 개발자를 위한 추상레이어를 제공하였다. 공동설집자들은 원탁회의를 열고 데이터 포맷을 JSML 또는 JSON으로 부를지, 라이선스 유형을 어떻게 가져갈지에 대해 투표하였다. 칩 모닝스타는 State Software에서 상태있는 응용 프레임워크를 위한 아이디어를 개발하였다.

이 시스템은 선 마이크로시스템스, 아마존닷컴 및 EDS에 판매되었다. 2002년 JSON.org 웹사이트가 만들어졌다. 2005년 12월, 야후에서는 몇몇 웹서비스를 JSON으로 제공하기 시작하였다.

JSON은 JavaScript 스크립트 언어(특히 1999년 표준 ECMA-262 3rd 에디션)의 부분집합에 기반하였으며, JavaScript에서 널리 사용되었지만, 언어 독립적인 데이터 포맷이다. 많은 프로그래밍 언어에서 JSON 데이터를 파싱하고 생성하는 코드를 사용할 수 있다. JSON의 웹사이트에는 언어별 JSON 라이브러리 목록이 있다.

2013년 10월, Ecma International에서는 JSON 표준 1차 에디션 ECMA-404를 발행하였다. 같은 해, RFC 7148은 ECMA-404를 참조로 사용하였다. 2014년에 FRC 7159는 JSON의 인터넷 이용이 주요 참조가 되었으며 RFC 4627 및 RGC 7158을 초과하였다. (ECMA-262와 ECMA-404를 주요 참조로 보존하였음) 2017년 11월, ISO/IEC JTC 1/SC 22에서는 ISO/IEC 21778:2017을 국제표준으로 발행하였다. 2017년 12월 13일, 인터넷 공학 태스크포스(Internet Engineering Task Force)는 국제표준 STD 90의 현 버전인 RFC 8259를 발행하면서 RFC 7159를 퇴출하였다.

크록포드는  JSON 라이브를 오픈소스화 하기 위해 JSON 라이선스에 한 절을 추가하면서 "소프트웨어는 선을 위해 사용어야지, 악을 위해 사용되어서는 안된다"고 하여 회사 변호사들과 과도하게 현학적인 사람들을 비웃었다. 반면 이 절은 다른 오픈소스 라이브러리와 JSON 라이선스의 라이선스 호환성 문제를 야기하였다.

문법(Syntax)

다음 예는 인간을 기술하는 JSON 표현을 보인것이다.

{
   "firstName": "John",
   "lastName": "Smith",
   "isAlive": true,
   "age": 27,
   "address": {
      "streetAddress": "21 2nd Street",
      "city": "New York",
      "state": "NY",
      "postalCode": "10021-3100"
   },
   "phoneNumbers": [
      {
         "type": "home",
         "number": "212 555-1234"
      },
      {
         "type": "office",
         "number": "646 555-4567"
      }
   ],
   "children": [],
   "spouse": null
}

문자 인코딩(Character encoding)

크록포드는 원래 JSON은 JavaScript와 ECMAScript의 엄격한 하위집합이라고 주장하고 믿었으나, 그의 사양은 실제로는 유효하지 않은 JavaScript인 JSON 문서를 허용한다. 즉, JSON은 유니코드 라인 종결자 U+2028 LINE SEPARATER와 U+2029 PARAGRAPH SEPARATOR가 따옴표로 묶은 문자열내에 이스케이프 처리를 하지 않고 나타날 수 있다. (ECMAScript 2018 및 이전 버전에서는 불가능하다. 이는 JSON이 "제어문자"만을 불허한 결과이다. 최대 이식성을 위해서는 이들 문자를 백슬래시로 이스케이프 처리를 하는 것이 좋다. 이는 JSONP를 생성할 때 중요하다.

개방 생태계에서 JSON 교환은 UTF-8로 인코딩해야 한다. 이 인코딩은 기본 다국적언어 평면(U+10000 에서 U+10FFFF)를 벗어나는 문자를 포함한 유니코드 문자셋 전체를 지원한다. 그러나 이스케이프처리하면 이들 글자는 UTF-16 surrogate pair를 사용하여 써야 하며, 일부 JSON 파서는 이런 상세함을 놓친다. 예를 들어 JSON에서 이모지 문자 U+1F610 😐 NEUTRAL FACE를 포함하려면 다음과 같이 해야 한다.

{ "face": "😐" }
// 또는 
{ "face": "\uD83D\uDE10" }

JSON은 ESMAScript 2019 리비전 이후 부터 해당 언어의 엄격한 하위집합이 되었다.

데이터 유형

JSON의 기본 데이터 유형은 다음과 같다.

• Number(수) : 분수 부분이나 지수표현 E를 포함할수 있는 부호있는 십진 수. 하지만, NaN과 같이 숫자가 아닌것은 포함하지 않는다. 정수와 소수를 구분하지 않는다. JavaScript는 모든 숫자값에 배밀도 부동소숫점 포맷을 사용한다. 나중에는 BigInt도 지원한다.) 하지만, JSON을 구현하는 다른 언어에서는 수를 다르게 인코딩할 수도 있다.
• String(문자열) : 0개 이상의 유니코드 문자 시퀀스. 문자열은 겹따옴표로 분리되며, 백슬래시 이스케이프 문법을 지원한다.
• Boolean(부울) : true 또는 false 값 중의 하나.
• Array(배열) : 0개 이상 값의 순서있는 목록. 각각의 값은 어느 유형이든 관계없다. 배열은 대괄호 표현을 사용하며, 요소는 쉼표로 구분한다.
• Object(객체) : 이름-값 쌍의 콜렉션으로서, 이때 이름(키)은 문자열이다. 객체는 사전(dictionary)를 표현하기 위한 의도로서, 각각의 키는 객체 내에서 유일하다. 객체는 중괄호로 구분되며, 각각의 쌍은 쉼표로 구분하고, 각각의 쌍내에서는 ':'을 사용하여 키와 값을 구분한다.
• null(널) : 단어 null을 사용하는, 비어있는 값

구문 요소(값 및 구두점) 주변의 화이트스페이스는 허용되고 무시된다(단, 문자열 값 내의 화이트스페이스는 그대로 사용된다).  이러한 목적의 화이트 스페이스는 공백(space), 수평탭(horizontal tab), 라인피드(line feed), 캐리지리턴(carriage return) 등 4가지 특정 문자가 고려된다. 특히 byte order mask가 적합한 구현에 의하여 생성되지 않아야 한다(JSON을 파싱할 때는 허용될 수 있다). JSON은 코멘트를 위한 문법은 제공하지 않는다.

(RFC 4627과 같은) 초기버전의 JSON의 경우, 유효한 JSON 텍스트가 객체 또는 배열유형만을 포함해야 했다(객체나 배열 내에 다른 유형이 들어갈 수 있다). 이 제한은 JSON 텍스트를 직렬화 값으로 재정의한 RFC 7158에서 제거되었다.

JSON에서 Number는 프로그래밍 언어내에서의 표현에 대하여 불가지하다. 이때문에 숫자를 임의의 정밀도로 직렬화할 수 있지만, 이는 이식성 문제를 야기할 수 있다. 예를 들어, 정수와 부동소수 값간의 차이가 없으므로, 어떤 구현에서는 42, 42.0, 4.2E+1을 동일한 수로 취급하고, 다른 시스템에서는 달리 처리할 수 있다. JSON 표준에서는 오버플로, 언더플로, 정밀도 상실, 반올림, 부호있는 0 과 같은 구현 상세에 관해 아무런 요구사항이 없지만, "좋은 상호운영성"을 위하여 IEEE 754 binary54 이상은 기대하지 않는 것을 추천한다. (binary64와 같은) 부동소수의 기계수준의 이진 표현을 인간이 읽을 수 있는 (JSON의 Number와 같은) 10진 표현으로 직렬화하거나 그 반대방향에서 내재적인 정밀도 상실은 없다. 이를 정확하게, 최적으로 수행하는, 발행된 알고리듬이 존재하기 때문이다.

코멘트는 JSON에서 의도적으로 배제되었다. 2012년에 더글라스 크록보드는 설계 결정에서 "사람들이 코멘트를 사용하여 파싱 지침을 넣거나하여 상호운영성을 파괴하는 사례를 보아서 JSON에서 코멘트를 제거했다"고 하였다.

JSON은 "뒤에 있는 쉼표", 즉 데이터 구조 내에서 마지막 값 뒤에 있는 쉼표를 허용하지 않는다. 이는 JSON 탄생 시점부터 ECMA 표준과 일치하기 위해서이다. 이후의 ECMA 표준에서는 뒤에있는 쉼표를 허용하기도 했지만, JSON 사양은 호환성 이유로 이를 계속 불허하였다. 뒤에 있는 쉼표는 JSON 파생체에서는 사용 용이성을 향상시키기 위한 일반적인 기능이다.

의미론(Semantics)

JSON은 데이터 교환을 위한 구문적 프레임워크를 제공하지만, 모호하지 않은 데이터 교환을 위해서는 JSON 문법의 특정한 사용을 위한 의미론에 생산자와 소비자간 합의도 필요하다. 이러한 합의가 필요한 예중 하나가 JSON 표준이 아닌 JavaScript 문접에서 정의된 데이터 유형(Date, Function, Regular Expression, undefined 등)의 직렬화이다.

메타데이터와 스키마

JSON 텍스트의 공식 MIME type은 "application/json" 으로서, 대부분의 현대 구현은 이를 수용하고 있다. 많은 서비스 제공자, 브라우저, 서버, 웹 응용, 라이브러리, 프레임워크 및 API에서는 예전 시스템과의 호환성을 이유로 비공식적 MIME type "text/json" 또는 콘텐트 타입 "text/javascript"도 지원하고 있다. 중요한 사례로는 구글 검색 API, 야후, 플리커, 페이스북 API, Lift framework, Dojo Toolkit 0.4 등이 있다.

JSON 스키마는 유효성검증, 문서화, 상호작용 제어 등에 사용되는 JSON 데이터 구조를 정의하기 위한 JSON 기반의 포맷을 명시한다. JSON 스키마는 주어진 응용에서 요구하는 JSON 데이터를 위한 계약과 데이터를 어떻게 수정할 수 있는지를 제공한다. JSON 스키마는 XML 스키마(XSD) 개념에 기반하지만, JSON 기반이다. XSD에서와 마찬가지로, 스키마와 데이터 모두 동일한 직렬화/역직렬화 도구를 사용할 수 있다. 즉, 자기기술적(self-describing)이다. JSON 스키마는 Internet Draft(IETF에서 2019-09 초안)에서 규정되었고, 2019년 9월 19일 공개되었다. 여러 프로그램 언어를 위한 여러가지 유효성 검증기가 존재하며, 각각 부합성 수준이 다르다. 표준 파일명 확장자는 없지만, 일부는 .schema.json을 제안하였다.

JSON 표준은 객체 참조를 지원하지 않지만, JSON 기반 객체 참조를 위한 IETF 표준 초안은 존재한다. Dojo Toolkit은 표준 JSON을 사용하여 객체 참조를 지원한다. 특별히 dojox.json.ref 모듈을 사용하면 순환참조, 다중참조, inter message, lay referencing 등을 포함한 여러가지 형태의 참조를 사용할 수 있다. 내부적으로는 두가지 모두 이러한 참조에 "$ref" 키를 부여하고 파싱시 이를 해결한다. IETF 초안은 URL 문법만 명시하지만, Dojo에서는 더 많은 형태를 허용한다. 다른 방법으로는 모질라 JavaScript Sharp 변수를 사용하는 등의 비 표준 해결책도 존재한다. 하지만, 이러한 기능은 JavaScript 1.8.5 이후로 막혔고, Firefox 12 버전에서 제거되었다.

용도

JSON-RPC는 JSON을 기반으로 만들어진 원격 프로시저 호출 (RPC: remote procedure call)로서, XML-RPC 또는 SOAP 를 대체한다. JSON-RPC는 약간의 데이터 유형과 명령만을 정의하는 간단한 프로토콜이다. JSON-RPC는 시스템에서 전송 통지를 시키고(응답이 필요하지 않는 서버에 대한 정보), 응답할 수 있는 서버에 다중호출을 보낸다.

비동기 자바스크립트 및 JSON (AJAJ, Asynchronous JavaScript and JSON)은 Ajax와 동일한 동적 웹페이지 방법론이지만, XML 대신 JSON을 데이터포맷으로 사용한다. AJAJ 는 웹브라우저가 데이터를 불러들인 후, 새로운 데이터를 요청할 수 있는 능력을 제공하는 웹 개발 기술이다. 전형적으로 웹페이지에 대한 사용자 반응에 대응하여, 서버로부터 새로운 데이터를 표시한다. 예를 들어, 사용자가 검색상자 등에 문자를 치면 이를 서버에 보내어 즉시 해당되는 데이터베이스 항목의 드롭다운 목록을 표시한다.

JSON은 데이터 직렬화 포맷이지만, 임시로(ad-hoc) 설정언어로서 사용되어 왔다. 이러한 사용에서는 코멘트와 기타 유용하다고 생각되는 기능을 지원함으로써, 비표준 JSON 상위집합이 생성되었다. 이중에는 HJSON, HOCON, JSON5(JSON 버전 5가 아님) 등이 있다. YAML 버전 1.2의 주요 목적은 엄격한 JSON 상위집합 비표준 포맷을 만드는 것이었다.

2012년, 더글라스 크록포드는 설정 언어로서 사용될 때 JSON에서 코멘트를 사용하는 데에 대해 말한 적이 있다. "일부 사람들이 코멘트 기능이 없어서 슬퍼한다는 것을 알지만, 그럴 필요가 없다. 당신이 JSON을 사용하고 주석을 달고 싶은 설정 파일을 유지한다고 생각해보자. 그러면 원하는 대로 코멘트를 삽입하고 JSMin 파이프를 통과시킨 후 JSON 파서에 넘기면 된다."

JSON은 데이터 직렬화 포맷으로서 의도되었다. 그러나, JavaScript의 하위집합으로 설계되었다는 사실에서, JSON 텍스트를 JavaScript eval() 함수에 넘겨도 안전하다는 잘못된 생각이 만들어졌다. 어떤 유효환 JSON 텍스트, 특히 U+2028 LINE SEPARATOR 또는 U+2029 PARAGRAPH SEPARATOR 를 포함하는 JSON 텍스트의 경우, 2019년에 JavaScript 사양이 갱신되기전 까지는 유효한 JavaScript 코드가 아니었기 때문에 일부 예전 엔진은 지원하지 않기 때문이다. 인터넷 혹은 새로운 함수에서 유래된 임의의 코드를 수행하는 데 따른 많은 함정을 피하기 위하여, ECMAScript의 5 판에는 JSON.parse()가 처음 추가되었고, 2017년에는 모든 주요 브라우저에서 지원되었다. 지원하지 않는 브라우저의 경우, 더글러스 크록포드가 API-호환 자바스크립트 라이브러리를 제공하고 있다. 아울러 TC39 제안 "Subsume JSON"은 ECMAScript를 2019년 버전부터 엄격한 JSON 상위집합으로 만들었다.

다른 포맷과의 비교

JSON은 XML에 대한 오버헤드가 적은 대체품으로 홍보되었다. 이들 포맷은 실세계 상황에서 생성, 읽기, 디코딩을 지원하기위해 널리 사용되고 있다. XML을 제외하고라도 CSV, YAML(JSON의 상위집합)을 포함할 수 있다. 또한, 데이터 교환 언어는 아니지만, Google Protocol Buffers가 이러한 역할을 채워줄 수 있다.

YAML

YAML 버전 1.2는 JSON의 상위집합이다. 이전 버전은 엄격하게 호환되지 않았다. 예를 들어, JSON에서는 백슬래시(\)를 사용하여 슬래시(/)를 이스케이프처리가 가능하지만, YAML에서는 유효하지 않았다. 이러한 이스케이프 처리는 JSON을 HTML에 넣어 cross-site scripting 공격을 보호할 때 널리 사용되는 방법이다. 

YAML은 코멘트를 지원하지만, JSON은 지원하지 않는다.

XML

XML은 구조화된 데이터를 설명하고 객체를 직렬화하는데 사용되어 왔다. 동일한 종류의 데이터 교환을 목적으로, JSON과 동일한 데이터 구조를 표현하는 여러가지 XML 기반의 프로토콜이 지원된다. 데이터를 XML 로 인코딩하는 방법은 여러가지가 있다. 두개의 태그를 사용한 가장 값비싼 형태를 사용하면, JSON보다 훨씬 크게 만들어지지만, 데이터를 속성에 저장하고 짧은 태그와 닫는 태그를 />로 대체하면, 표현이 JSON과 거의 비슷해지거나 약간 커지는 정도가 된다. 그러나, XML 속성은 단일 값만 사용할 수 있고, 각 속성은 각각의 요소에 많아야 한번 나올 수 있다.

XML은 (요소와 속성을 사용하여) "데이터"를 "메타데이터"와 분리하지만, JSON에는 그러한 개념이 없다.

다른 중요 차이는 값에 대한 주소지정 방법이다. JSON은 단순한 "키"와 "값" 매핑만 있는 객체를 사용하지만, XML은 "노드"단에서 주소지정이 발생하여, 모든 노드가 XML 프로세서에서 고유 ID를 부여받는다. 추가적으로 XML 표준은 공통 속성 xml:id 를 정의하여, 사용자가 사용할 수 있고 ID를 명시적으로 지정할 수 있다.

XML 태그 명은 !"#$%&'()*+,/;<=>?@[\]^`{|}~ 및 화이트 스페이스를 포함할 수 없고, 마이너스(-), 마침표(.) 및 숫자로 시작할 수 있지만, JSON 키는 가능하다(단, 따옴표와 역슬래시는 반드시 이스케이프 처리해야 한다). 

XML 값은 문자(character)의 문자열이며, 내장 유형 에러방지가 없다. XML은 스키마의 개념이 있어서, 강력한 유형지정, 사용자 정의 유형, 선 정의한 태그, 형식적 구조, XML 스트림에 대한 정식 유효성 검증 등이 가능하다. JSON의 경우 강한 유형지정이 내장되어 있고, JSON 스키마에서 비슷한 스키마 개념이 있다.

XML은 코멘트를 지원하지만, JSON은 지원하지 않는다.

파생

JSON 사양을 기초로 여러가지 직렬화 포맷이 만들어졌다. GeoJSON, JSON-LD, Smile (데이터 교환 포맷), UBJSON, JSON-RPC, JsonML 등이 그러한 예이다.

함께 보기

• 데이터 직렬화 포맷 비교
• Jacson(API)
• JSON 스트리밍
• S-expression

==

원문 : JSON - Wikipedia

ISO/TC 211 "자동 문서화(Automated Documentation" 특별그룹(AHG, Ad-hoc group)의 정식 멤버로 활동하게 되었습니다.

ISO 표준문서를 보면, UML 모델과 설명이 상이한 경우가 많습니다. 초안을 만든 뒤, UML을 수정하였으나 설명부분은 수정이 안되는 경우, 등등으로 인해 이러한 오류가 발생합니다. 이 특별그룹은 모든 설명을 UML 등의 모델에 작성하여 자동으로 ISO 표준 문서를 작성함으로써, 이러한 오류를 없애고자 하는 것이 목표입니다.

이 특별그룹 관련 저장소는 : https://github.com/ISO-TC211/AutomatedDocumentation 입니다.

AHG 5 "자동 문서화" 특별 그룹의 두 가지 주요 임무

규정적 선언(Normative statements)

규정적 선언, 적합성 클래스와 시험은 실행 코드가 아닌 순수한 문장으로 쓰여지는 경우가 많다. 이들이 기계가 읽을(machine-readable) 수 있어야 하는지, 가능하다면, 기계가 시험할(machine-testable) 수 있어야 하는지에 대해 의문이 있어왔다. 하지만, 모든 선언이 기계가 시험할 수 있는 것은 아니다. 기계가 읽을 수 있는 선언은 선언에 대해 구조화된 모델이 필요할 것이다. OGC는 자신의 표준을 위해 요구사항 모델을 정의하였다. 이 특별그룹은 <<statement>> 모델 초안을 개발해야 한다. 이 모델은 ISO 19105 모델과 연결되어야 하며, 향후 표준화를 위한 입력으로서 작용해야 한다.

모델-기반 문서화(Model-driven Documentation)

어떤 특별 그룹(ref ISO/TC 211 resolution 633)에서는 2013년, ISO TC/211 표준의 모델-파생 문서화에 대해 연구하였다. Enterprise Architect 및 ShapeChange를 위한 템플릿이 개발되었으며, github.com/ISO-TC211/UML-Best-Practices/wiki/DocumentationOfUmlModels 에서 볼 수 있다. 템플릿은 많이 사용되지 않았으며, 아마도 ISO 19135-1에서만 사용되었다. 하지만, ISO 19170-1은 EA로부터, EA => ShapeChange => Metanorma => ISO 문서 로 생성된 바 있다. 이 특별 그룹은 모델-파생 문서화에 대한 접근법 및 ISO/TC 211 표준화 프로젝트에서 활용하는 방법에 대해 연구할 것이다.

아래는 Ribose에서 발표한 자료입니다. 확실한 내용은 모르겠지만, Metanorma라는 도구를 사용하면 EA(또는 .xmi)에서 구축한 모델을 docx 파일로 변환이 가능하다는 것 같습니다.

여기에 들어가면 예전(2013)에 문서 자동화를 검토하며 만들어둔 템플릿을 볼 수 있습니다. 

• EA 템플릿
• ShapeChange 설정 및 시험용 UML 모델

아래는 이에 대한 자세한 문서입니다. 시간날 때 정리해보겠습니다. 

민, 푸른하늘

지리정보를 UML로 모델링하기 위한 모범 사례에 대한 ISO/TC211 위키

이 위키의 목적은 지리정보를 UML로 모델링하기 위한 모범사례를 수집하고 표현하며, 기계와 인간이 모두 이해할 수 있는 모델을 제작하기 위함이다.

1. 개요

1.1 UML 기본

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Basic-UML

1.1.1 UML 소개

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Introduction-to-UML

UML은 무엇인가?

• UML은 객체지향 모델링을 위한 그래픽 언어
• Unified Modelling Language의 약어
• Object Management Group(www.omg.org)에서 개발
• UML 2.4.1 이 ISO 19505:2012 로 국제 표준화되어 있음

UML 다이어그램

그래픽 언어는 그래픽 모델 요소가 있는 다이어그램으로 구성된다. 아울러 모델링 도구는 모델 요소에 대한 문자 정의를 저장한다. 그래픽 언어가 충분하지 않을 경우, 자신만의 정확한 문자 언어로서 키워드 및 제약을 입력할 수도 있다.

UML에는 정보, 행태(behaviour), 유스케이스, 컴포넌트 등을 기술하는 여러가지 다이어그램이 있다. 지리정보는 주로 아래와 같은 3가지 정적 모델을 사용하여 기술한다.

• 패키지 다이어그램 : 패키지와, 패키지 간의 관계를 표시한다.
• 클래스 다이어그램 : 클래스와 클래스 간의 연관을 표시한다. 클래스 다이어그램은 클래스 명과 속성을 보인다.
      - 클래스에는 이름, 속성, 연산이 포함됨. 제한(constraints)와 tagged value가 표시될 수도 있음 
      - 속성은 속성명, 데이터유형, 다중도 로 표현됨
      - ApplicationSchema, FeatureType, dataType, enumeration, CodeList, interface, Union 등의
        스테레오타입이 있음
      - association role에서 탐색가능한 종점은 반드시 이름과 다중도가 있어야 함
• 객체 다이어그램은 실세계를 설명하는 실제 인스턴스를 나타낸다.

• UML 패키지는 여러 요소 그룹을 위한 콘테이너이며, 패키지 다이어그램에서는 탭이 있는 폴더로서 표현된다.
• 패키지 의존성(dependency)은 어떤 패키지의 클래스가 다른 패키지에 있는 클래스를 필요로 함을 나타낸다. 이는 점선으로 표시하며, 꼬리쪽 패키지를 위해서 화살표 쪽에 있는 패키지가 필요함을 나타낸다.

• 스테레오타입이 "ApplicationSchema"인 패키지에는 지형지물(feature) 유형을 포함한다. 이 스테레오타입은 GML 실현시 중요하다.
• 스테레오타입이 "FeatureType"인 클래스는 지리 객체 유형을 표현한다. 이 스테레오타입은 GML 실현시 중요하다.
• 스테레오타입이 "dataType"인 클래스는 식별성이 없는 특질의 집합이다. 이러한 클래스는 단독 인스턴스로서는 존재할 수 없고, 다른 클래스의 속성 혹은 컴포넌트로만 존재할 수 있다.
• 스테레오타입이 "enumeration"인 클래스는 가능한 값이 정해진 고정 목록이다. 이러한 목록을 사용하는 속성의 값은 반드시 그 목록내에 존재해야 한다.
• 스테레오타입이 "CodeList"인 클래스는 가능한 값이 확장될 수 있는 목록이다.
• 스테레오타입이 "interface"인 클래스는 개념적 클래스이다. 이러한 클래스는 데이터 셋에서 직접 사용될 수 없으며, 다른 클래스에서 실현되어야 한다.
• 스테레오타입이 "Union"인 클래스는 여러가지 유형 목록을 포함하며, 하나의 인스턴스에서 하나의 유형만 사용된다.
  

연관관계

• 연관관계는 연관명을 가질 수 있다.
• 연관관계는 방향이 있을 수 있다. 이는 연관관계가 탐색가능한(navigable) 방향을 보이는 화살표로 표시한다.
• 탐색가능한 끝은 연관역할명(role name)과 다중도(연결 인스턴스의 가능한 수)를 가져야 한다.
• 빈 다이아몬드가 있는 연관관계를 집합연관(aggregation)이라고 하며, 다이아몬드가 있는 쪽의 클래스가 반대쪽 개별 콤포넌트의 집합을 갖게 된다.
• 채운 다이아몬드가 있는 연관관계를 합성연관(composition)이라고 하며, 다이아몬드가 있는 쪽의 클래스가 반대쪽 컴포넌트를 소유한다.
• 클래스간의 상속성(Inheritance)는 빈 삼각형이 있는 선으로 표현되며, 삼각형이 있는 쪽의 클래스가 상위클래스이다.

1.1.2 추상화 수준(Level of Abstraction)

"추상화수준"이란, 모델에서 묘사한 상세함의 정도 및 특정 구현에 대하여 그 상세함이 얼마나 구체적인지를 의미한다. 모델의 추상화수준은 기반 패턴의 정의로부터, 개념의 정의, 그리고 플랫폼 구현사양까지 여러 단계가 있다.

ISO 19103에서 설명한 4가지 추상화수준은 다음과 같다.

1. 메타모델(가장 추상적임. ISO19109의 일반 지형지물 모델(General Feature Model)과 ISO19505의 UML 메타모델 등)
2. 개념스키마 - 추상 스키마 (기본개념에 대한 핵심 모델. 예 : ISO19107의 기하 및 위상 등)
3. 개념스키마 - 응용 스키마 (아직까지 개념 모델이나, 특정 응용에 위함. 예: 길, 건물 등)
4. 구현스키마(특정 구현을 위한 스키마. 예 : GML 응용스키마(XSD))

1.2 Enterprise Architect 사용하기

1.2.1 유용한 도구(script, search, addin 등)

• Enterprise Architect 스크립트 작성법 - 샘플 스크립트 - 문서제작 스크립트, .eap 파일 정보 보기, 모델 검증 등
• Enterprise Architect에서 모델 검색용 스크립트 작성법
• ShapeChange 플러그인

1.2.2 INSPIRE 투토리얼

 INSPIRE_UML_repository_tutorial.pdf

참고로 이 파일은 다음 세가지 부분으로 이루어짐.

- EA를 사용하여 UML 모델 생성하기
- EA와 Subversion 사용하기
- EA와 Subversion 저장소 사용하기

1.3 참고 문헌

1.3.1 요구사항 및 권고사항

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Requirements-and-recomendations

여러가지 ISO/TC211 표준 및 기술사양에는 UML 모델링에 관한 규칙과 권고사항이 들어 있다. 이중 일부는 이 위키문서에도 들어 있지만, 지리정보 UML 모델을 작업하는 사람은 반드시 원 문서를 알아두어야 한다.

ISO 19103 - 개념 스키마 언어

ISO 19103:2015에는 ISO 지리정보 표준에서 개념스키마 언어를 사용하는 규칙 및 지침이 포함되어 있다. 선택된 개념 스키마 언어는 통합 모델링 언어(UML)이다.

이 표준에는 다음과 같은 요구사항 및 권고사항이 포함된 UML 프로파일이 있다.

- UML 일반 용법
- 클래스
- 속성
- 데이터 유형
- 연산
- 관계 및 연관관계
- 선택/조건부/필수 속성 및 연관관계
- 이름 명명법 및 네임스페이스
- 패키지
- 노트(Note)
- 제약(Constraints)
- 모델 문서화

ISO 19109 - 응용 스키마 규칙

ISO 19109:2015에서는 지형지물 정의 원칙을 포함하여, 응용스키마 생성 및 문서화에 대한 규칙 및 권고사항이 정의되어 있다. 그 초점은 논의의 영역에 속한 지형지물 및 속성에 대한개념 모델링이다.

- 응용스키마의 정의
- 응용스키마를 위한 개념 스키마 언어 사용법
- 개념 모델의 개념을 응용스키마의 데이터 유형으로 변환하는 방법
- 다른 ISO 지리정보표준에 있는 표준 스키마와 응용스키마를 통합하는 방법

19136 GML(부속서 E)

ISO 19136:2007은 지리마크업언어(GML)에 대한 XML 스키마 문법, 메커니즘 및 공통규약을 정의한다. ISO 19136:2007 부속서 E(규정)에는 ISO 19109/19103에 적합한 UML 응용스키마를 GML 응용스키마로 자동 매칭하는 것을 목표로 하는 규칙을 담고 있다. 이 부속서에는 다음 항목에 대한 인코딩 법칙을 서술한다.

- 응용스키마와 패키지
- 클래스
- 속성
- 연관관계 및 연관관계 끝

19139 XML 스키마 구현

ISO/TS 19139:2007 에서는 ISO 19115에서 유도된 XML 스키마 구현인 지리 메타데이터 XML (gmd : Geographic Metadata XML) 인코딩을 정의한다. 여기에는 UML로부터 XML로 매핑시키기 위한 일반 법칙이 담겨있는데, 다른 표준을 XML로 구현할 때에도 유용하다.

1.3.2 기타 유용한 문서

- ISO/TC211, OGC, INSPIRE의 지리정보 UML 모델링
    INSPIRE Repository tutorial : Enterprise Architect, 모델링, svn 저장소 사용법 등에 대한 소개
    OGC Domain modelling cookbook : 지리정보 도메인 모델을 구축및 유지관리 모범사례
    Domain Modelling using Hollow World 
    Presentation 2015(Data modelling and model driven implementation of data distribution)
- SVN 및 문서관리
   Enterprise Architect를 위한 버전 제어 모범 사례
   ISO/TC211 조화 모델 소개 - 조화모델 불러오기

- 프로파일
   ISO/DIS 19160-1 개념 모델 처리하기, 부속서 B : 프로파일 개발 지침
   ISO/DIS 19160-1 개념 모델 처리하기, 부속서 C : 샘플 프로파일
- 구현
   주소 : 뉴질랜드 개념 모델(프로파일), 부속서 I, 개념모델을 구현모델로 전환하는 방법
   주소 : 뉴질랜드 개념 모델(프로파일), 부속서 B/C, 데이터 유형을 실현하는 방법 예시 

- 스크립트 
    Querying EA's Database : [Inside Enterpise Architect : EA 데이터베이스 쿼리, Thomas Kilian]
    Scripting Enterprise Architect [Enterprise Architect 스크립트 작성법, Thomas Kilian]
    Fifty Enterprise Architect Tricks [Enterprise Architect를 위한 50가지 트릭, Peter Doomen]

- ISO/TC211 내의 논의
   UML에 대한 문제점 토론사항 

2. 모범 사례

2.1 관련 요구사항 및 권고사항

- 1.3.1 과 동일

2.2 모델링 모범사례

2.2.1 일반 - 추상화 수준

- 1.1.2와 동일

2.2.2 일반 - 패키지/클래스/속성의 명명법

접두사(GM_, TP_ 등)

예전 UML 편집기에는 다른 패키지에도 동일한 이름의 요소를 포함할 수 없는 "버그"가 있었다. 이러한 이유로, ISO TC 211에서는 기본적으로, 분류자(Classifier) 이름에 "네임스페이스" 접두사를 붙였다.(예: 기하의 경우 "GM_", 위상의 경우 "TP_") 현재 편집기에는 패키지 분리가 올바르게 이루어지므로, 따라서

하지만 일부의 경우 사람의 가독성을 위하여 접두사가 가치가 있을 수 있다. 하지만, 경험적인 법칙으로는 접두사 대신 다이어그램에 네임스페이스를 표시하는 것이 좋다.

** 기존 표준에서 사용된 접두어는 Prefixes 페이지에서 볼 수 있다.

규칙과 권고사항

19103에는 패키지, 클래스, 속성, 역할의 명명에 대한 여러가지 규칙 및 권고사항이 있다., 그중 핵심은 다음과 같다.

GML을 구현하기 위하여, ISO 19136 GML에서는 이름을 W3C XML 네임스페이스에 정의된 "NCName" 이어야 한다고 요구한다. NCName은 위의 요구사항보다 좀더 제한적이며, 일반 문자/숫자/("-",".","_") 등만 사용할 수 있고, "!", "#", "?" 등과 같은 특수문자는 사용할 수 없다. 아울러 NCName은 숫자/"-","." 로 시작할 수 없다. (뒤쪽에는 나타날 수 있다.)

참고: 속성과 역할의 경우, 네임스페이스가 클래스이므로, 이 규칙에 따르면 다른 클래스에서 반복사용될 수 있다. 하지만, ISO 19109 (응용 스키마 규칙)의 권고사항에 따르면

이 권고사항은 GFM 권고사항인 rec/general/property-name과 밀접한 관계가 있다. 

아울러 아래의 ISO 19103의 권고사항을 따른다.

예: 클래스 명이 "Building"일 경우, 속성명은 "buildingName" 대신 "name" 을 쓴다.)

즉, 속성/연산/역할/매개변수는 lowerCamelCase, 패키지/클래스/연관은 UpperCamelCase 형태로 만든다.

예) 클래스 이름은 TransportLink 처럼 될 수 있으며, validFrom 과 validTo와 같은 속성을 가질 수 있다.

다중언어 이름

ISO19109 응용스키마에는 이름을 다중언어로 처리하는 방법에 관한 몇가지 요구사항이 존재한다.  응용 스키마가 있는 패키지의 경우, 주요 언어를 가진 태그값을 가져야 한다.

예 : "Observation et Mesures"@fr

지형지물 유형, 속성, 역할, 연산도 TAGGED VALUE를 사용하여 다른 언어로 표현할 수 있다.

실세계 이름과 UML 이름

모델요소의 이름이 "분류자를 위한 정확하고 이해가능하며 기술적인 이름"이어야 하지만, 공백과 특수문자를 가질 수 없고 실 세계 이름과 다르게 될 수 있다. 예를 들어, transport link 클래스는 "TransportLink"가 되며, 기능적 도로등급은 "FuctionalRaodClass"가 된다. 사람의 가독성을 위하여,  alias로 실세계 이름 넣는 것이 좋다. 

2.2.3 일반 - 정의

모델요소 잘 정의하는 것은 사람들이 모델을 잘 이해하는데 중요하다. UML에서는 정의를 Notes필드에 적으며, tagged value에도 쓸 수 있다.  ISO 19103 및 ISO 19109에서는 패키지/클래스/속성의 정의에 대한 여러가지 규칙과 권고가 있다. 기본적으로 이 모든 권고의 내용은

19103 규칙 및 권고사항

일반

Enumeration/codelist

Naming 과 네임스페이스

모델의 문서화 

10109 규칙 및 권고사항

응용스키마 문서화 

정의 작성 방법

Enterprise Architect에서 "UML 도구에서 제공하는 주요 문서화 기능"은 각각의 클래스/속성/역할/연산/제약에 대한 "Note" 필드이다. 정의는 이 필드에 기록해하며, 다음과 같이 작성해야 한다.

• 가능한한 간결하고 예제나 설명은 포함하지 않아야 한다. (예나 설명은 "description"에 넣을 것)
• "주소란..." "Address component is..." 처럼 시작하지 않아야 한다.
• 마침표(".")로 끝내야 한다.

예 : 특정 지리적 구역, 위치 혹은 주소 범위를 정의하는 기타 공간 객체의 식별자 또는 지리적 명칭. (Identifier or geographic name of a specific geographic area, location, or other spatial object which defines the scope of an address.)

2차적 설명 - TAGGED VALUE "description"

2차적 설명은 태그 값 "description"에 기록할 수 있다.

자연언어 명칭

예:

address component

보완적 설명(complementary description)

• 정의의 출처 참조는 키워드 SOURCE를 사용하여 포함시킬 수 있으며, 그 뒤에 Source의 약칭을 넣어야 한다.
• 설명에서 추가적 해설은 키워드 NOTE를 사용하여 넣을 수 있다. 노트가 여러개 있을 경우, NOTE 1, NOTE 2 등 처럼 번호를 넣는다.
• 예는 키워드 EXAMPLE을 사용하여 넣을 수 있다. 예가 여러개 있을 경우, EXAMPLE 1, EXAMPLE 2 와 같이 번호를 넣는다.

• 행정 단위명(Administrative unit name), 국가명, 도시명, 거리명 등을 포함할 수 있다.
• 주소 지역명 예: 마을 혹은 단지명
• 가로명(Thoroughfare name) 대부분 도로명 
• 우편 설명자. 주소를 구성하기 위하여 

2.2.4 일반 - TAGGED VALUE

태그 값 tagged value란?

스테레오타입과 태그 값(Tagged Value)를 사용하면 기존의 UML 모델요소를 새로운 목적으로 확장시킬 수 있다. tagged value는 tag와 값의 쌍으로서, UML 모델요소에 특질을 추가한다. UML 2에서는 tag 정의가 있는 스테레오타입이 부여된 모델 요소에만 tagged value를 적용할 수 있다. 태그 값은 tag=value의 형태로 나타나며, 여기에서 tag는 태그명, value는 문자열값(literal value)이다. Tagged value는 특히 코드 생성 이나 설정 관리와 깊은 관계가 있다.

예 : 분류자에 추가된 태그값은 다음과 같이 정의될 수 있다.
{author="Joe Smith", deadline = 31 March 1997, status = analysis}

Tagged value는 스테레오타입에 대한 속성으로서 정의된다. 예를 들어 스테레오타입 CodeList에 대한 속성인 codeList는 어떤 기관에서 별도 관리하는 원래의 코드 목록에 대한 URI 참조값을 나타낸다.

19103의 tagged value

CodeList        codelist        실제 외부 코드 목록을 참조하는 영구 URI

19109의 tagged value

19136(부속서 E)의 tagged value

2.2.5 일반 - 모델의 버전

UML 모델이 개정됨에 따라, 다른 버전별로 새로운 패키지가 생성되고, 전체 모델 저장소에는 동일한 클래스에 대하여 여러가지 버전이 존재하게 된다.

예를 들어, CI_Citation 클래스는 ISO/TC211 개념 모벨 저장소에 세가지 장소에서 정의되고 있다.

• ISO 19115:2003 Metadata
• ISO 19115:2006 Metadata(Corrigendum)
• ISO 19115-1:2014 Metadata - Fundamentals

이 검색 결과에서 CI_Citation 클래스가 어떤 버전에서 나온것인지 보기는 불가능하다. 날짜(특히 "Modified")에서 개략적으로 알수는 있지만, 이는 확실한 것이 아니다. Enterprise Architect에서 자동적으로 설정하고 갱신되기 때문이다.

상태, 페이즈, 버전(Statue, Phase and Version)

Enterprise Architect에는 Status, Phase, Version 등, 요소 및 패키지에 대한 유용한 메타데이터가 몇가지 존재한다. 이들 매개변수는 버전을 식별하는데 유용하며, 모든 패키지 및 요소에 대하여 한번의 작업으로 설정할 수 있다. Project Browser -> 패키지에 우클릭 -> Advanced->Update Package Status

상태 (Status)

상태는 Enterprise Architect에서 미리 정의된 코드 목록(Approved, Implemented, Mandatory, Proposed, Validated)에 기반하고 있다. (이들 코드 목록은 Project-Settings-Project Types-General Types에서 변경할 수 있다.)

ISO/TC211 표준의 개념 모델의 경우 가장 관련있는 값들은 다음과 같다.

• Approved : 공식 표준 및 기술 사양을 위한 UML 모델
• Proposed : 개발중인 표준 및 기술사양을 위한 UML 모델
• Implemented : 구현 스키마를 위한 UML 모델
• Superseded : 대체된 표준을 위한 UML 모델

페이즈 (Phase)

Phase는 자유 기재이지만, ISO/TC 211 모델의 경우, 공식 페이즈를 사용하는 것이 자연스럽다.

• WD : Working Draft
• CD : Commitee Draft
• DIS : Draft International Standard
• FDIS : Final Draft International Standard
• IS : International Standard
• DTS : Draft Technical Specification
• TS : Technical Specification

국가 또는 지역 모델에 대해서는 다른 값을 적용할 수도 있다.

버전(Version)

버전도 자유 기재이다. ISO/TC211 모델의 경우 모델이 발행된 년도이다. 국가 또는 지역 모델에 대해서는 다른 값을 적용할 수도 있다.

보기

아래 그림은 상태 값을 갱신하기 전, MI_BAND 클래스에 대한 검색 결과이다.

아래 그림은 상태 값이 갱신된 동일한 검색결과이다. 어떤 클래스를 사용해야 할 지 훨씬 쉽게 구분할 수 있다.

2.2.6 클래스 - 스테레오 타입

1.1.1 의 스테레오타입과 동일함 

2.2.7 클래스 - 일반화/특수화

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Generalization

개요

상위클래스로의 일반화(Generalization) 및 하위클래스로의 특수화(Specialization)은 도메인 모델링의 중요하면서도 가치있는 부분이다. 상위클래스로부터 하위클래스로 상속성을 사용하면 모델에서 중복성을 줄이며, 공통 개념을 동일한 방식으로 취급할 수 있다.

아래 그림은 하위클래스와 상위클래스의 예를 보인 것이다. 차량(Vehicle)은 자동차(Car) 및 열차(Train)의 상위 클래스이다.

다른 예로서 ISO 19157 데이터 품질에는 추상 상위클래스 DQ_Result와 여러가지 다른 결과 유형을 위한 하위클래스를 볼 수 있다.

하위클래스로의 특수화

하위클래스로 특수화하는 주로 필요한 것은, 클래스의 식별된 부분에만 적용되는 속성/연관 또는 연산이 있을 경우이다.

예를 들어 DQ_Result의 각 하위클래스에 있는 속성은 해당 종류의 결과에만 적용된다. 하지만, 특별한 속성, 연관 혹은 연산이 없더라도 하위클래스가 개념적으로 다른 경우와 같은 상황도 있다. 위의 그림에서 Train이 이에 해당한다. 하위클래스 Train은 특별한 속성이나 연관관계가 없지만, 자동차와는 개념적으로 다르다. 이러한 하위클래스는 주의깊게 사용해야 하며, 모델을 복잡하게 만들 수 있다.

하위클래스는 속성, 연관, 연산의 중복을 줄일 수 있는 중요한 것이지만, 주의깊게 사용해야 한다. 불필요한 하위클래스는 모델을 복잡하게 만든다. 위와 같은 의도가 없는 이상 하위클래스를 생성하지 말라.

상위클래스로의 일반화

상위클래스로 일반화하는 주로 필요한 것은, 여러가지 클래스가 동일한 속성/연관 또는 연산을 가진 동일한 개념의 변종일 경우이다.

예를 들어 그림 위에서 Car 및 Train은 탑승차량의 일종이며, 승객수가 있을 수 있다. 또한 DQ_Result 아래에 있는 모든 하위클래스는 날짜와 범위가 있는 여러가지 결과이다. 이때 Vehicle 과 DQ_Result 상위클래스를 사용하면, 상당한 중복이 줄어들며, 동일한 개념을 모든 하위클래시를 위해 사용할 수 있게 된다.

상위클래스로 일반화할 수 있는지를 알아보기 위해서는 두가지 간단한 법칙을 고려해야 한다.

• 100% 법칙 : 상위클래스에서 필요한 모든 속성 및 연관이 모든 하위클래스에도 적용할 수 있다.
• Is a 법칙 : 자연어에서 "하위클래스가 상위클래스의 일종이다"라는 문장을 테스트해본다. (예: 열차는 차량이다.)

많은 경우, 상위클래스는 추상 클래스이며, 하위클래스는 구현되는 클래스이다.

2.2.8 클래스 - 추상클래스

1.1.1 클래스와 동일

2.2.9 클래스 - 클래스/데이터유형

UML 모델에서 개념 클래스는 물리적객체(강/도로/건물 등)를 표현할 수 있지만, 추상적객체(조직/거래/관측 등)도 표현할 수 있다. 도메인 모델링에서 처음 해야 하면서도 가장 중요한 작업이 개념 클래스를 식별하는 것이다.

데이터타입은 특별한 종류의 분류자이다. 클래스와는 유사하다. 데이터유형의 인스턴스는 값으로만 식별할 수 있다. 즉, 자체적으로 식별되는 인스턴스는 될 수 없고, 속성(및 연관) 값으로서만 존재할 수 있다. 각각의 값을 구분하는 것이 의미가 없을 때 주로 사용된다.

어떤 것이 클래스(ISO/TC211 응용스키마에서는 지형지물 유형)인가 데이터유형인 속성인가하는 의문이 자주 등장한다. 이에 대한 엄격한 답은 없다. 다만, UML 모델링에서 가장 기본되는 법칙은, 모델과 모델의 구현을 가능한한 간단하게 하라는 것이다. 또한 데이터 유형의 값은 자체적으로 존재할 수 없고, 관련된 클래스의 값으로서만 존재한다. 무차별적으로 복합데이터 유형을 사용하면, 객체내 데이터 양을 증가시킨다. GML에서의 예를 들어보자. 클래스에 대한 연관은 xlink:href로 사용할 수 있지만, 데이터 유형에 대한 연관은 항상 인라인이 된다. 데이터 유형 인스턴스는 객체 바깥에서는 존재할 수 없기 때문이다.

따라서, 데이터타입보다는 지형지물유형을 사용하는 것이 더 좋다. 기본 법칙은 아래와 같다.

2.2.10 속성 - 속성인가 연관인가

이 글은 Geert Bleekeen의 블로그 글 속성인가 연관인가를 참고한 것이다. 클래스와 데이터 유형에 대해서는 윗 글을 참고할 것

ISO 19109에 있는 UML 및 일반지형지물모델(GFM)에는 객체에 특성을 제공하는 두가지 비슷한 방법 - 속성 및 연관관계 - 을 보여준다. 객체의 특성을 위한 간단한 방법은 19103의 원시 데이터유형(Integer, CharacterString 등)의 속성을 사용하는 것이다. 하지만 자체적으로 여러개의 속성을 가지고 있는 복합 데이터 유형을 속성으로 가질 수 있다. 예를 들어 ISO 19115의 Citation의 여러가지 클래스 및 데이터 유형은 다른 표준에서 클래스의 특질로서 널리 사용된다. 이러한 경우 흔히 제기되는 의문이, 언제 복합 데이터유형을 속성으로 사용할지, 언제 연관으로 사용할 지 하는 것이다.

일반지형지물모델(GFM)에서 속성과 연관은 모두 PropertyType의 하위유형으로 많은 점에서 동등하다. GeertBeelkens의 블로그 글에서 기술한 것처럼, 이들은 UML 메타모델에서 동일한 메카니즘에 근거하고 있고, 구현에서도 거의 동일하다. (GML에서 연관은 속성과 비슷함)

게다가 UML 사양에 따르면, "데이터 유형은 클래스와 유사한 특별한 종류의 분류자이다. 데이터 유형은 값으로만 식별될 수 있다는 점만 클래스와 다르다"고 기술하고 있다. 달리 말해 데이터 유형의 인스턴스는 자체적으로 존재하는 객체가 아니며, 구현에서 관련된 객체의 일부이어야 한다.

가장 기본적인 법칙은 특성이 어떠한 분류자에 기반하는지 살피는 것이다. 즉 데이터 유형인가 지형지물 유형인가 하는 것이다. 그것이 지형지물 유형이라면 주 지형지물의 외부에 존재할 수 있고, 그 경우에는 연관으로서 참조만 가능하다.

반대로 분류자가 데이터 유형이면(이 글의 법칙을 따른 후에도) 데이터 유형의 값은 주 지형지물이 연관에 기반하는지 아니면 속성에 기반하는지에 따른다. 위에서 언급한 것처럼 연관은 GML에서 속성과 매우 유사한 형태이다. 따라서 데이터 유형에 기반한 특성이라면 속성으로 사용하는 것이 좋다.

아울러 동일한 원칙에 기반하여 데이터 유형에 대한 간단한 연관은 의미가 없으며 반드시 합성연관이어야 한다. 이는 ISO 19103의 요구사항 12에도 언급되어 있다.

2.2.11 속성 - 다중도(Multiplicity)

1.1.1 클래스 와 동일함.

2.2.12 속성 - 속성에 data type 연결하기

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Attributes-and-data-types

지형지물유형, 객체유형, 데이터유형, 유니온유형의 속성은 이름과 데이터 유형이 있어야 한다. 이는 ISO 19109 응용 스키마 규칙 및 ISO 19136 GML에도 언급되어 있다. 이들 표준이 응용스키마와 관련되어 있기는 하지만, 개념 모델에도 동일한 규칙이 적용된다. 이는 모델의구현을 위해 중요하다.

데이터 유형은 ISO 19103에 미리 정의된 원시데이터 유형, 또는 다른 표준에서 정의된 유형, UML모델에서 자체적으로 정의한 유형 등 중의 하나이어야 한다.

UML 모델링에서 가장 흔한 오류중 하나는 속성 유형에, 기본 클래스에 연결하지 않은 이름을 지정하는 것이다.(예를 들어 data 유형에 그냥 "GM_Point"라고 입력하는 것은, ISO 19107 기본 모델에서 선택ㅎ하는 것과 동일하지 않다.) 다이어그램 상으로는 올바른 것처럼 보여도, 연결이 빠졌기 때문에, 구현이나 의존성 점검시 오류가 발생한다.

Enterprise Architect의 속성 테이블(t_attribute)에서, 속성은 데이터 유형에 연결되는 ClassifierID를 가져야 한다. 올바르게 이 링크를 올바르게 하려면, 절대 이름을 직접 입력하지말고, 항상 모델에서 선택해야 한다. 

불행하게도, EA에는 속성이 데이터 유형과 연결되었는지를 제어하는 기능이 존재하지 않는다. 하지만, 이는 검색 혹은 스크립트를 활용하면 된다. 아래 링크에는 데이터 유형 연결을 체크할 수 있는 스크립트 예제가 있다.

https://github.com/ISO-TC211/UML-Best-Practices/blob/master/Scripts/VBScript/VAL%20Data%20type%20references.vbs

2.2.13 연관 - 연관의 유형

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Association-types

이 글은 Geert Bellkeen의 블로그 글 "합성연관, 집합연관, 연관관계"를 참조한 것이다.

연관관계는 모델에서 클래스 또는 데이터 유형을 연결할 때 사용된다. UML에서는 클래스 다이어그램에 단순 연관(association), 집합연관(aggregation), 합성연관(composition) 등세가지 연관관계를 지원한다. (일반화는 별도)  모든 연관은 단방향 혹은 양방향으로 탐색가능(navigable)할 수 있다. 화살표/다중도/역할 등으로 정의된다.

• 단순연관은 두개의 클래스가 동등한 입장이다. 위의 그림에서 Person 클래스와 Car 클래스간에는 단순 연관이 있다. 사람은 차를 0개 이상 가질 수 있으며, 차는 1명 이상의 소유자가 있다. 이들은 모두 동등한 수준으로 서로 다른 것의 일부가 아니다.
• 집합관계(aggregation, 빈 다이아몬드로 표시)에서는. 다이아몬드 쪽의 클래스가 전체이며, 다른 쪽에 있는 클래스가 일부이다. 예를 들어 위원회는 전체이며, 위원은 사람이다. 하지만, 사람(위원)은 위원회에 독립적으로 전해 할 수 있고, 다른 위원회에 소속될 수도 있고, 다른 클래스의 일부일 수도 있다. 위원회가 사라지더라도 사람은 존재한다.
• 합성관계(composition, 채운 다이아몬드로 표시)에서는 다이아몬드 쪽의 클래스가 다른쪽 클래스를 소유한다. 예를 들어 차(Car)는 바퀴(Wheel)을 소유한다. 다이아몬드쪽의 다중도에 따라 반대쪽 클래스가 독립적으로 존재할 수 있는지가 결정된다. 그림에서 Car 쪽의 다중도가 0..1 이므로, Wheel은 Car가 없이도 존재할 수 있다. 합성관계일 경우, 현실적으로는 [0..1] 또는 [1] 다중도만 존재한다.

2.2.14 연관 - 역할과 탐색가능성(navigability)

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Association-roles-and-navigability

탐색가능성(navigability)

UML 클래스/데이터유형간의 연관은 탐색가능 방향을 가질 수 있다. 단방향(출처->대상 혹은 대상->출처)일수도 있고, 양방향일 수도 있다. 탐색가능 방향을 Unspecified로 지정할 수도 있으며, 이경우 대부분 양방향과 동일하지만, 사용해서는 안된다. 탐색가능 방향은 모델 구현이 탐색가능한지를 기술하며, 다이어그램에서는 화살표로 표시한다. 위의 그림에서는 모든 연관이 양방향으로 탐색가능하다.

탐색가능 방향은 구현에서 영향을 미친다.

또한 양방향 연관은 두 클래스 모두의 구현에서 서로에 대해 알아야 함을 의미한다. 이로 인하여 구현이 좀더 복잡해 질 수 있다. 양방향이 모두 필수일 경우, GML 구현에서 두 클래스는 서로 참조를 가져야 한다.

양방향은 서로 상대방을 알수 있는 구현으로 구현이 복잡하다. 즉, 서로 참조를 가져야 한다.

역할명(role name)

구현에서는 연관은 속성과 비슷하다. 따라서 다음 사항이 중요하다.

위의 그림에서 Person 클래스의 구현은 Car 클래스의 구현에 대한 참조를 가질 수 있으며, 이 참조의 이름은 자산(property)어야 한다. 또한 역으로 Car 클래스의 구현은 Person 클래스의 구현에 대한 참조가 있어야 하며, 이 참조의 이름은 owner이어야 한다. 하지만, Car와 Wheel간의 연관을 살펴보면, Car 쪽 끝에는 이름이 없다. 따라서 Wheel 클래스는 Car에 대한 참조를 알 수 없다.

다중도(Multiplicity)

연관 역할의 다중도는 한 클래스의 인스턴스가 다른 쪽 클래스를 몇개 참조할 수 있는지를 기술한다. Person 클래스는 0개이상의 Car 인스턴스를 참조할 수 있지만, Car는 한명 이상의 Person(owner)를 가져야 한다. 위원회(Committee)는 2명 이상의 위원(Person)이 있어야 하며, 위원은 0개 이상의 위원회에 속할 수 있다. 또한 Car는 3개 이상의 Wheel을 가져야 하지만, Wheel은 0개 또는 1개의 차에 속해야 한다.

다중도의 설정도 구현에서 중요하다.

다중도를 1 또는 1... 로 설정할 경우, 해당 클래스의 구현은 항상 이 참조를 필수로 가져야 한다.(필수 속성과 비슷).  Car-Wheel 연관에서 Car 쪽의 다중도가 1로 설정되었다면, Wheel 클래스는 Car 클래스의 구현에 대한 참조가 반드시 존재해야 한다. 또한 Wheel 쪽의 다중도는 이미 (3..*)이다. 모델이 이런식일 경우, 구현에서 두 개의 클래스가 서로 반대쪽을 참조해야 하며, 이로 인해 데이터의 중복이 일어나게 된다.

2.2.15 연관 - INSPIRE Repository Tutorial

https://github.com/ISO-TC211/UML-Best-Practices/blob/master/Reference%20material/INSPIRE_UML_repository_tutorial.pdf 12-13쪽 참조

연관을 생성한 뒤에는 반드시 특성을 지정할 것. (특히 탐색가능 방향 및 역할 명)

역할명은 lowerCamelCase로 쓸 것. Notes 필드에 definition 과 description 적을 것. 

탐색이 불가능한 종점에서는 역할명/다중도/스테레오타입/tagged value 등이 관련 없다.

2.2.16 작업중

• 네임스페이스 : UML 패키지와 XML 네임스페이스의 연결

• 제약 https://github.com/ISO-TC211/UML-Best-Practices/wiki/Constraints
• OCL : INSPIRE Repository tutorial 10-11
• 표시방법 : INSPIRE Repository tutorial 14쪽

• 프로파일
• 기존 모델의 확장 또는 프로파일링 :

2.3 클래스 다이어그램 모범사례

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Best-practices-for-diagram-design

클래스 다이어그램은 모델의 일부에 대한 뷰이며, 모든 측면을 보여주지 않을 수 있다. 하지만, 모델에 대한 인간의 이해를 위해 중요한 그림이다. 이 페이지는 쉽게 이해할 수 있으며, 깔끔하고 일관성 있는 클래스 다이어그램을 생성하기 위한 모범사례를 담고 있다.

2.3.1 필요한 다이어그램

19103 개념 스키마 언어에는 문서화를 위해 포함시켜야 하는 다이어그램를 포함하여, 모델의 문서화를 위한 규칙/권고사항이 있다.  

필요한 다이어그램

19103 개념 스키마 언어에는 문서화를 위해 포함시켜야 하는 다이어그램를 포함하여, 모델의 문서화를 위한 규칙/권고사항이 있다.  아울러 포함하면 유용한 다이어그램도 있다.

패키지 다이어그램

[[패키지 의존성 다이어그램]]

ISO 19103 요구사항 17 및 21에 따르면, 하나이상의 패키지 다이어그램에 (외부 패키지 포함한) 패키지간 의존성을 표현해야 한다. 

클래스 다이어그램

ISO 19103 및 ISO 19109에 있는 규칙과 별도로, 클래스 다이어그램을 위한 주요 모범사례는 모든 분류자(클래스, 코드 목록, 열거형, 데이터 유형)가 가 적어도 하나의 클래스 다이어그램에 표현되어야 한다는 것이다. 이 스크립트를 사용하면 이 규칙을 확인할 수 있다. 아울러 모든 속성, 연관, 연산, 제약은 적어도 하나의 다이어그램에 표현되어야 한다.

[[High Level 개요 다이어그램]]

주요 클래스와 연관만  있는 고수준 개요 다이어그램을 사용하면 모델을 잘 소개할 수 있다. 이 다이어그램에서는 속성 및 역할 명은 숨겨야 한다.

[[상세 개요 다이어그램]]

ISO 19103 추천사항 16에 따르면, 모든 패키지는 모든 클래스가 표시되는 (속성/연산/역할등은 숨김) 개요 다이어그램이 필요하다. 맥락을 이해하는 데 중요할 경우 속성/연산/역할 등을 표시할 수도 있다.

[[Perspective specific diagram]]

모델의 특정 부분, 주요 분류자에 중점을 둔 다이어그램은 모델의 이해에 유용하다. 적을수록 좋다(less is more)는 원칙을 기억하라. 하나의 다이어그램에 등장하는 요소가 적을 수록 가독성이 높아진다. 관점에 관련 없는 속성은 표시하지 말라.

[[Codelist, enumeration, data types]]

하나의 패키지에 있는 모든 codelist/enumeration/data type을 하나의 다이어그램에 표현한 다이어그램도 유용하다. 이런 분류자들은 다른 패키지에서 재사용되는 경우가 많으므로, 이처럼 하나의 다이어그램에 모두 모아두면 많이 도움이 된다.

[[각 분류자에 대한 Context Diagram]]

ISO 19103 요구사항 18에 따르면, 모든 분류자는 Context diagram에 표현해야 한다. 여기에는 모든 속성/연산 및 해당 분류자에서 탐색가능한 모든 관계를 표시해야 한다. 관계가 깊은 분류자의 경우, Context 다이어그램을 공유할 수 있다. 하지만,적을수록 좋다(less is more)는 원칙을 다시 한번 기억하라. 한 다이어그램에 등장요소가 적을수록, 관점이 적을 수록가독성이 높아진다.

유스케이스 및 시퀀스 다이어그램

유스케이스 다이어그램과 시퀀스 다이어그램은 모델 개발 과정에서 중요한 역할을 한다.

---- 앞으로 설명 및 예제를 추가할 예정 ---

객체 다이어그램

클래스의 인스턴스가 들어 있는 객체 다이어그램은 모델의 이해와 테스트에 매우 중요하다. ISO/TC211에 있는 객체 다이어그램의 예는 ISO 19160-1에서 볼 수 있다. ISO 19160-1 프로파일을 개발할 때, 몇몇 샘플 주소를 위한 객체 다이어그램이 필수이다. 

아래 그림은 ISO 19160-1의 INSPIRE 프로파일을 위한 객체 다이어그램이다.

2.3.2 클래스 다이어그램 디자인

폰트/색

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Colours-and-fonts

[[폰트]]

19103 개념스키마 언어에는 다이어그램의 폰트 크기에 관한 추천사항이 하나 있다.

이 권고사항도 모범사례 적을수록 좋다(less is more)와 관련이 있다. 다이어그램은 추천된 폰트 크리로 프린트할 수 있는 정도의 크기어야 한다.

INSPIRE Repository tutorial 의 규약에 따르면

모든 모델에서 이 규칙을 따를 것을 추천한다.

[[색]]

다른 지형지물 카탈로그에서 가져온 클래스를 다른 색으로 표현하면 이해하는 데 도움이 된다. 하지만, 다음 사항을 기억해야 한다.

ISO 표준(문서)의 그림들엔 색이 없어야 한다. 하지만, ISO 모델 및 기타 모델에서 다이어그램에 색이 사용되고 있다. 하지만, ISO 표준 및 동일한 요구사항이 있는 문서에서 사용할 경우, 반드시 흑백으로 export 시켜야 한다. 예를 들어, INSPIRE와 관련된 국가 사양에서는 INSPIRE 클래스에 색깔을 사용할 수 있다. 하지만 다음 사항을 지켜야 한다.

ISO 19160-1 주소 - 개념모델에서는 표준 프로파일 문서화를 위한 요구사항 및 추천사항이 있다. 이들은 다른 모델에도 적용할 수 있다. (7.5.2장)

[[속성]]  

현재 색이 다른 클래스에 대해 속성을 부여하는 것이 불가능하다. 여기 및 여기를 참고할 것. (두개 모두 깨진 링크)

적을수록 좋다(Less is more)

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Less-is-more

이 글은 Geert Bellkeen의 블로그 글 5 rules for better UML diagrams 를 참조한 것이다.

• 복잡한 모델을 위한 대형,  압도적인 다이어그램 보다는, 여러개의 작은 다이어그램으로 분리
• 각각의 UML 다이어그램은 소수의 요소에 집중하고 정의된 관점이 있을 것.
• 다이어그램의 관점과 관련이 먼 속성/연관/제한은 숨길 것

ISO 19157에서 가져온 아래 그림에서, 목적은 데이터품질 단위가 DQ_DataQuality와 하나 이상의 DQ_Element로 구성됨을 보이는 것이다. DQ_Element의 속성은 이 관점에서는 관련이 없으므로, 보이지 않도록 하였다. 아울러 DQ_Element의 연관요소도 관련이 없으므로 숨김 처리했다.

요소가 많이 들어 있는 개요 다이어그램도 있을 수 있다. 이러한 다이어그램은 요소와 연관만 보이고 속성은 숨겨야 한다. 연관의 역할명도 숨기는 것이 좋을 수 있다.

[[속성 표시여부 선택하기]]

한 요소의 속성/연산/제약/노트 표시/숨기기 : 해당 요소 우클릭 - Features & Properties -> Feature and Compartment Visibility (Cntl-Sht-Y)
모든 요소의 속성/연산/제약/노트 표시/숨기기 : 해당 다이어그램 선택(F5) - Properties - Element

[[역할명 표시여부 선택]]

하나의 역할 명 : 레이블 우클릭 -> Hide label
연관의 모든 레이블 숨기기 : 연관 우클릭 - Visibility -> Hide all labels
연관 label 중 일부 숨기기 : 연관 우클릭 -> Visibility -> Set label visibility

[[연관 표시여부]]

하나의 연관 : 연관 우클릭 - Visibility - Hide Connector
여러개의 연관 : Diagram - Visible Relations?? (Cntl-Sht-I)
모든 연관 : Diagram 을 우클릭 - Properties - Connectors - Show relations

연관 관계 선을 직각 표시(Orthogonality)

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Orthogonality

이 글을 Geert Bellkeen의 블로그 글 5 rules for better UML diagrams 를 참조한 것이다.

잘 정돈된 다이어그램은 어지러운 것보다. 이해하기 쉽다. 요소들을 수평/수직으로 정돈하고 직각 연결선을 사용하는 것은 가독성을 향상시키기 위한 첫번째 단계이다.

아래 첫 그림에서, 요소는 자동 정렬되어 있고, 연결선은 직선으로 되어 있다. 그 다음 그림은 수평/수직으로 정렬되어 있으며, 동일한 간격으로 조화된 크기로 맞췄으며, 연결선은 직간으로 처리했다. 이 그림은 좀더 정렬되어 이해하기 쉽다.

지저분함:

정렬된 그림:

요소를 정렬하고 높이를 맞추는 도구는 원하는 요소들을 선택하고 우클릭하면 접근할 수 있다. 라인 스타일은 선 선택 - 우클릭 - Line Style에서 설정할 수 있다. 위 예제의 라인 스타일은 Tree Style - Vertical 이다. 이 스타일은 세개의 하위 클래스가 모두 DQ_Result에 대하여 동일한 관계가 있기 때문에 사용할 수 있다. 만약 이들 중 하나가 다른 관계(예: 집합관계)가 있을 경우, 이는 별ㄷ의 선으로서 표시되어야 한다.

다른 표준에서 온 클래스 표시

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Illustrate-classes-from-other-standards

대부분의 표준은 다른 표준으로부터 클래스나 코드목록을 포함한다. 다이어그램을 잘 이해하기 위해서는 이들 요소들이 어느 표준에서 유래했는지를 도시해야 한다. 이 페이지에서는 이를 위한 두가지 접근법을 제시한다.

[[첫번째 방법 : 경계선(Boundary)]]

외부 요소를 표시하는 간단하면서도 유용한 방법은 다이어그램에서 요소 둘레로 경계선을 추가한 뒤, 표준의 이름과 번호(및 연도)를 텍스트로 추가하는 것이다. 이렇게 하면 쉽고도 직관적인 표현이 가능하다.

아래 그림은 ISO19157:2013 지리정보-데이터 품질에서 사용한 방법이다.

Enterpise Architect에서는 Toolbox 중에서 Common 그룹에 들어 있다.

이 방법의 단점은 외부 표준의 이름이 변경되었을 경우, 텍스트가 자동적으로 변경되지 않는다는 점이다.

[[두번째 방법 : 네임스페이스를 모두 표시]]

또다른, 좀더 유용한 해법은 아래 그림과 같이 외부 클래스의 완전한 네임스페이스를 모두 표시하는 방법이다. 이렇게 하면, 표준명 뿐만 아니라, 어떤 패키지가 이 요소를 소유하는지를 보일 수 있다. 하지만, 문장이 길어지고 혼란스러워질 수 있다.

완전한 네임스페이스를 보이려면, 다이어그램을 선택한뒤, Properties - Diagram - Show Namespace 및 Fully Qualified Namespace 를 선택하면 된다. (단, 외부에서 가져온 것 뿐만 아니라, 모든 것의 네임스페이스가 표시됨)

선을 교차시키지 말것

https://github.com/ISO-TC211/UML-Best-Practices/wiki/No-crossings

이 글은 Geert Bellkeens 의 블로그 글 5 rules for better UML diagrams 중에서 2번째 규칙을 참조한 것이다.

상위 요소를 위쪽으로 배치

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Parents-up

이 글은 Geert Bellkeens 의 블로그 글 5 rules for better UML diagrams 을 참조한 것이다.

게층에서 가장 높은 요소는 다이어그램에서도 제일 높은 곳에 위치해야 한다. 

• 하위 클래스는 상위 클래스 아래에 위치시킨다.
• 집합 관계의 경우, 소유하는 측의 요소가 부분 요소의 아래로 내려가서는 안된다.
• 구현의 경우, 원 요소가 위에 있어야 한다.

크기를 조화롭게

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Harmonize-sizes

이 글은 Geert Bellkeens 의 블로그 글 5 rules for better UML diagrams 을 참조한 것이다.

모델 요소의 크기를 조율하면, 가독성을 향상시킬 수 있다. 중요도가 동일한 하위클래스와 연관클래스는 가능한 한 크기가 같아야 한다. 또한 직교성을 유지하기 위해서는 요소의 높이를 통일시킬 필요가 있다.

아래의 그림에서 DQ_Result의 하위 클래스 3개는 모두 중요도가 같지만, 속성의 수가 다르다. 원하는 요소들을 한꺼번에 선택한 후, 우클릭 - Same Height and Width를 선택하면 모두 동일한 크기로 설정할 수 있다.

아래 그림에서 DQ_Element에 대한 연관 클래스도 중요도가 동일하다는 것을 보이기 위해 동일한 크기로 설정하였다. 연관 클래스의 속성은 그림과 관련 없기 때문에 가독성 향상을 위하여 숨김처리하였다. (적을수록 좋다를 참고할 것)

제약(Constrains) 표시

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Constraints

[[제약이란]]

제약이란, "요소의 의미론을 선언하기 위한 목적으로 자연언어 혹은 기계가독언어로 표시한 제한이나 조건"이다(ISO 19103).  제약은 예를 들어, 어떠한 조건하에 속성이 필수가 되는지 등의 조건을 설정함으로써, 모델에 정밀함을 추가하므로 중요하다. 개념 수준에서 제약을 표현하는 것은 검증, 관리 및 데이터 관리에 중요하다.

ISO 19109에는 여러가지 제약의 예가 있다.

• 제약은 하나이상의 지형지물 인스턴스(다른 데이터 유형에 속한 것도 무방)에 있는 속성 값의 허용 조합을 지정할 수 있다.
• 제약은 지형지물 인스턴스간의 연관관계 다중도를 제한할 수 있다.
• 제약은 실세계 현상이 어떤 크기일 경우, 지형지물 인스턴스가 어떤 GM_Object의 하위유형으로 표현될 것을 요구할 수 있다.
• 지형지물 연산에서 정의된 지형지물의 행태는, 제약으로서 제한할 수 있다.

UML에서 제약은 자연언어 또는 기계가독언어, 일반적으로 객체 제약 언어(OCL, Object Constraint Language)로 표현할 수 있다. ISO 19103 권고사항14에 따르면, "제약은 OCL 2.0에 정의된 객체 제약 언어를 사용하여 표현한다. 또한 제약은 모델에 대한 문서에서 자연언어로 기술한다."고 되어 있다. OCL 표현은 구현에 중요하며(필수는 아님), 자연언어 표현은 인간의 이해에 중요하다.

[[자연어로서 먼저 작성하라]]

OCL로 제약을 작성하는 것은 직관적이지 않으므로, 먼저 자연어를 기술한 후, 이를 근거로 OCL을 추가한다.

[[OCL 작성방법]]

• INSPIRE Repository tuturial 10-11에는 OCL을 작성하는 방법에 관한 힌트가 있다.
• 과거 및 현재의 OCL 사양은 http://www.omg.org/spec/OCL/에서 볼 수 있다.
• OCL 작성을 위한 지침. CABOT, Jordi and GOGOLLA, Martin. Object Constraint Language (OCL): A Definitive Guide. In : Formal Methods for Model-Driven Engineering. Springer Berlin Heidelberg, 2012. p. 58–90. Lecture Notes in Computer Science.

[[구현에서 제약 활용 방법]]

제약을 구현에서 사용함에 있어, ISO 19136 (GML) 부속서 E 의 내용을 참조한다. "모든 OCL 제약은 무시한다. 인스턴스 모델이 제약조건에 맞는지 평가하는 것은 GML인스턴스를 처리하는 응용에서 담당할 몫이다. 비고: Schematron 언어를 사용하여 OCL 제약을 GML 응용스키마를 표현하는 XML 스키마의일부로서 표현할 수 있다." 이는 GML 응용 스키마는 제약을 포함하지 않으며, 제약은 Schematron이나 데이터를 처리하는데 사용하는 응용에서 처리해야 한다는 의미이다.

ShapeChange를 사용하면 스키마에 정의된 OCL 제약을 파싱할 수 있다. ShapeChange는 OCL 제약으로부터 Schematron 규칙을 유도할 수 있다. OCL->Schematron 변환에 관한 자세한 내용은 여기를 참고하라.)

[[EA에서 제약 사용하기]]

== 클래스 수준에서 제약 기술하기

• 제약은 반드시 클래스에 대한 특질으로서 서술되어야 한다. 다이어그램 및 다른용도, 모델 문서화에서 제약이 항상 클래스 를 따라다니도록 하기 위함이다.
• 제약을 속성 수진에서도 쓸수 있지만, 추천하지 않는다. 다이어그램에서 속성에 추가된 제약을 표현할 방법이 없는 것처럼 보이기 때문이다.
• 다이어그램 노트로서 제약을 쓸 수도 있지만, 이렇게 해서는 안된다. 이렇게 만들면 제약이 다이어그램의 일부가 되고, 클래스의 일부가 안되기 때문이다.

클래스/열거형/데이터 유형의 제약은 Properties 다이얼로그에서 Constraints 탭에서 접근할 수 있다.

• OCL을 쓸경우, Type=OCL로 선택하라. 자연언어 표현은 다음방법으로 추가할 수 있다.
• 해당 제약의 이름
• 코멘트 /*... */로 처리하여 제약 내부
• 자연언어로만 제약을 작성할 경우에는 Type=Invariant로 선택하라.

== 제약을 다이어그램에 표시하는 방법

제약은 UML 다이어그램에서 2가지 방법으로 표시할 수 있다. 첫번째는 요소에 첨부된 노트, 두번째는 클래스를 나타내는 요소 내에 표현하는 방법이다. 일반적으로제약은 클래스 내부에 표현하는 것을 추천한다. 아래 그림은 제약을 클래스 내에 표시하는 방법과, 노트로서 표현하는 방법을 보인 것이다.

• 다이어그램 전체의 제약을 표시하려면, 다이어그램 우클릭(F5) - Properties - Element 를 선택하고 Constrains 를 켠다.
• 특정 한 요소의 제한을 표시하려면, 요소 우클릭 - Feature and Compartment Visibility(Cntrl-Sht-Y)를 선택하고 Constrains 를 켠다.

어떤 경우, 어떤 특정한 제약을 요소에 첨부된 노트로서 표시하는 것이 좋을 수 있다. 이 경우, 다이어그램에 노트를 추가하고, 요소에 이를 연결하면 된다. 링크 우클릭 - "Link this note to an element feature"를 선택한다. 이때 나타나는 다이얼로그에서 Feature Type = Constraint 를 선택하고, Feature 목록에서 원하는 제약을 선택한다.

2.3.3 모델 문서화

• 다이어그램을  이미지 파일로 내보내기  
• 모델의 자동 문서화 (아래 3. 모델문서화 링크)

3. 모델 문서화

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Documentation

3.1 모델의 자동 문서화

https://github.com/ISO-TC211/UML-Best-Practices/wiki/DocumentationOfUmlModels

ISO/TC 211 애드혹 그룹에서는 UML로부터 문서화하는 방법에 대해 조사하였다. 적용 범위는 어떤 모델인지 명확하지 않았지만, 작업과정에서 ISO/TC 211 조화모델에 있는 UML 모델에 집중하였다. 이는 UML모델 저장소로서 ISO/TC 211 표준의 일부이다.

하지만, 문서화 도구는 조화모델 포함 여부에 관계없이, ISO 19103에 따라 모델링된 어떠한 UML 모델에도 적용할 수 있다. 

UML 문서 자동생성은 전세계, 지역, 지역(국가) 수준의 UML 응용스키마에 대해서도 유용할 것이다.

문서화 도구는 아래 문서에서 사용할 수 있다. 링크는 여기

 Automatic generation of documentation from UML models.docx

EA 용 템플릿은 아래에 있다. 링크는 여기

 ISOTC11_EA_report_template.zip

ShapeChange 설정 방법 및 UML 모델 테스트는 여기를 볼 것

3.2 모델의 버전

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Model-versions

2.2.5 일반 - 모델의 버전와 동일함

3.3 다이어그램을 이미지 파일로 내보내기

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Diagram-export

Enterprise Architect에 있는 Diagram 메뉴에서 다이어그램을 이미지로 저장할 수 있다.(단축키 Ctrl-T) 다이어그램을 클립보드로 복사하려면 Ctrl-B를 누른다.

기본값으로서, 다이어그램은 shading 되고, 다이어그램 이름이 레이블로 달리는 프레임이 생성된다. 쉐이드, 프레임, 레이블을 없애는 방법은 다음과 같다.

쉐이드 삭제

Tools - Options - Diagram - Themes 에 들어가서 Monochrome for printing을 선택한다.

프레임 제거:

Tools - Options - Diagramsㅇ로부터 Diagram Frames를 제거한다. 아울러 scale을 200%로 저장하면 문서에서 최적의 해상도를 얻을 수 있다.

4. 도구, 스크립트 등

4.1 Enterprise Architect 스크립트

4.1.1 EA 샘플 스크립트

https://github.com/ISO-TC211/UML-Best-Practices/tree/master/Scripts

아래는 Visual Basic Script의 내용임

https://github.com/ISO-TC211/UML-Best-Practices/tree/master/Scripts/VBScript

모델을 바꿔주는 스크립트(CHG)

• CHG Sort elements.vbs - 선택된 패키지에서 요소들 정렬
• CHG Save Project As.vbs - 프로젝트 복사본 저장

• DOC Count subpackages.vbs - 선택된 패키지에서 1단계 하위 패키지 수 
• DOC Export diagrams as images.vbs - 다이어그램을 이미지 파일로 저장
• DOC Export mapping files.vbs - 태그값에 기반한 매핑 파일 내보내기
• DOC List prefixes.vbs - 클래스와 열거형을 위한 모든 접두사 목록

• VAL Data type references.vbs - 데이터 유형 참조 목록을 만들고 빠진 참조 보고
• VAL Duplicate element names.vbs - 중복 요소명 식별
• VAL Elements in diagrams.vbs - 선택된 패키지 혹은 하위패키지에 있는 다이어그램에서 사용되지 않는 요소 식별
• VAL Missing definitions.vbs - 정의가 없는 요소 및 속성 목록
• VAL Model Validation.vbs - ISO 19103:2015 및 ISO 19109:2015에 정의된 규칙에 따른 모델 요소 검증

• VC Add Subpackages.vbs - 버전 관리를 위한 패키지 추가
• VC Get All Lates.vbs - 선택된 패키지 및 하위패키지를 위한 모든 최신 것을 가져옴
• VC Resync Status.vbs - 버전 관리 청소 - 선택된 패키지 및 하위패키지를 루핑하면서 VC Provider에 상태를 다시 싱크함
• VC Remove Version Control.vbs - 버전 관리 제거. 선택된 패키지 및 하위패키지를 루핑하면서 버전 관리 제거

• HMMG Script
• Version Control Script

• 노르웨이 매핑기관의 스크립트 : https://github.com/kartverket/UML-modelleringsskript

4.2 EA에서 모델 찾기

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Model-searches-in-Enterprise-Architect

4.2.1 EA 모델에서 검색

EA에서, 원하는 요소를 빨리 찾기 위해서는 model searches를 시행하면 된다. (Project Browser Toolbar에서 접근가능한, Find in Project Browser 버튼을 사용한 검색과 혼동하지 말라). Search는 Edit - Find in Project or Edit - Search in Model(Ctrl-F 또는 Ctrl+Alt+A)에서 접근할 수 있다. Search 드롭다운에서 검색을 한 뒤 Run 버튼을 누른다.

"Find in Project(Ctl-F)"의 여러가지 기능 (Start - Explore - Search - Search in Model)

[[미리 정해진 찾기 기능(Built-in Search)]]

EA의 Search 드롭다운에는 "Built-in"이라는 미리 정의된 검색 이 있다.

[[XML 파일로부터 가져온 검색]]

검색을 XML 로부터 import할 수 있다.(최상위 태그가 <RootSearch>) Search Builder Toolbar에서 Import Search를 누르면된다. XML파일로부터 가져온 검색은 검색 드롭다운에서 "My Searches" 범주에 나타난다.

[[MDG Technology의 일부인 검색]]

MDG Techonology(최상위 태그가 <MDG.Technology>)는 Tools - MDG Technology Import에서 가져올 수 있다. MDG Techonology의 일부로 가져온 검색은 검색 드롭다운에서 MDG Techonology라는 이름의 범주로 나타난다.

4.2.2 새로운 검색 정의 생성

1. Edit - Find in Project (Ctrl-F 또는 Ctrl+Alt+A)
2. Builder 버튼을 클릭한다.
3. 새로운 검색 정의를 생성한다. 이름을 주고 Editor Type이 SQL Editor인지 확인한다.

4.2.3 검증시 검색을 사용하기

검색을 사용하여 클래스, 속성, 기타 UML 요소가 특정 요구사항이나 권고사항에 부합하지 않는 요소를 알아낼 수 있다.

---- 향후 작업

4.2.4 검색 공유

검색 불러오기 및 내보내기

Search Builder 툴바에 있는 Export Search 버튼을 사용하면 다이얼로그 박스가 나타나고, 여기에서 XML 파일로 내보내고자하는 검색을 선택할 수 있다. 이 XML 파일을 Import Search 버튼을 사용하면 다른 사람이 불러올 수 있다.

참고로, 불러들이는 검색 정의가 이미 있는 검색정의와 이름이 중복될 경우, 동일한 이름을 가진 두개의 검색 정의가 생긴다. 

이러한 XML 파일은 UML 모델과 동일한 저장소에 저장할 수도 있다.

MDG Technology에서 Bundle Search

--- 향후 작업

4.2.5 검색 팁

CLASSGUID 와 CLASSTYPE

결과 셋(result set)의 일부로 CLASSGUID 와 CLASSTYPE을 지정할 경우, EA는 각 결과줄 앞에 해당 아이콘을 그려준다. 결과 셋에서 더블클릭하면 요소, 연산 및 속성이 직접 열린다. 다이어그램과 패키지는 직접 열리지 않는다. 이들은 Alt-G를 통해 프로젝트 브라우저에서 찾은 후 열어야 한다. Inside Enterprise Architect, EA User Guide 참고

4.3 ShapeChange plugin

https://kartverket.no/geodataarbeid/standarder/sosi/programmer-og-verktoy/

이 페이지에서는 SOSI 정의 파일의 품질관리 및 제품사양 생성에 도움이 되는 프로그램과 도구를 다운로드 받을 수 있다.

EA용 설정 프로젝트 파일

이 프로젝트 파일에는 SOSI 전체 모델 등록물을 포함하며, 문서화 템플릿, SOSI 모델 검증기, SOSI UML 프로파일 5.0 등이 있다. EA에서 여는 방법은 설치 가이드를 참고하라.

Download SOSI Model Register (eap, 350 MB)

SOSI 문서화 템플릿 (EA)

최종 SOSI 제품사양의 정보모델(5장)에 해당하는 UML 모델의 그림 및 텍스트 설명을 내보내기 위하여 EA에 설치해야 할 RTF 템플릿

Download SOSI documentation template in EA (xml) - updated 28.09.2017

SOSI 문서 RTF로부터 DOCS

EA 보고서를 향상시키는 마크로가 담겨있는 Word 템플릿. 정보모델을 제품사양서에 입력하기 전.

Download SOSI documentation from RTF to DOCX (dotm) - updated 28.09.2017

Shape Change

ShapeChange는 UML 모델로부터 GML을 생성하는데 사용된다. 자세한 매뉴얼은 www.shapechange.net에서 확인할 것

EA의 SOSI 플러그인

이 플러그인은 UML 모델로부터 SOSI 관리 및 SOSI 실현을 위한 정의 파일을 생성하기 위한 것이다. 이 플러그인의 일부로서 SOSI UML 프로파일이 설치된다.

이 EA 플러그인은 Arkitektum AS에서 개발하였다.

Download SOSI plugin in EA version 2.0.0.28 (exe)

SOSI UML 프로파일 5.0

이 프로파일은 표준 스테레오타입을 정의한다.

Download SOSI UML profile (xml)

SOSI 모델 검증 Add-on 1.0

이 도구는 EA 애드온으로서, 당신의 모델이 UML Modelling 5.0 규칙의 요구사항 및 권고사항을 충족시키는지를 점검하기 위한 목적이다.

Download SOSI Model Validation from the Mapping Authority's Github account .

UML 모델링 스크립트

노르웨이 매핑기관의 Github 계정에는 UML 모델을 작업할 때 도움이 되는 (예를 들어, 제품사양을 위한 모델 준비시 사용하는)스크립트를 몇개 올려두었다. 이들 스크립트는 EA용이다. 

SOSI_ps

제품 사양 문서를 위한 출발점을 생성하는 프로그램

Download SOSI_ps version 28.10.2013 (zip)

4.4 ShapeChange를 이용하여 조화 모델로부터 XML 스키마 생성

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

4.4.1 소프트웨어 요구사항

이 절은 아주 개략적인 내용이다. 자세한 내용은 조화모델 관리그룹 위키를 보라

Enterprise Architect(EA) : ISO/TC 211 조화 UML 모델을 개발/갱신관리하는데 사용되는 상용 소프트웨어 패키지. 여기에서 설명하는 내용은 12.1.1230을 기반으로 한다. 2017-07 현재 EA의 버전은 13.5이나, 여기에 있는 절차는 새로운 버전으로 테스트하지 못했다.

ISO/TC 211 조화 모델 : ISO/TC 211 조화모델은 웹에서 접근가능한 디렉토리에 저장되어 있으며, 여기에는 TC 211 작업과정에서 만들어진 모든 UML 모델을 담고 있는 파일이 들어있다. 모델은 EA로 부터 XMI(XML interchange format for UML)을 사용하여 export하였으며, 이들 XMI 파일은 온라인 디렉토리에서 버전관리를 하고 있다.(,아래의 Subversion 참고) Enterprise Architect외의 UML 모델링 소프트웨어 패키지도 XMI 파일을 사용할 수 있지만, 실질적으로 모델의 모든 측면(노트, 태그, 색깔 등)을 번역할 수 있을 만큼 충분히 신뢰할 정도로 포맷이 표준화되어 있지 않다. TC 211 조화모델에 있는 XML 문서는 다음과 같은 네임스페이스를 사용하고 있으며(xmi.version="1'1", xmlns:UML="omg.org/UML1.3", EA exporter 버전은 2.5이고, windows-1252 캐릭터 인코딩을 사용하고 있다.

Subversion : TC 211 조화모델 저장소는 Subversion 소프트웨어를 사용하여 관리되고 있다. Subversion은 Apache Software Foundation의 오픈소스 패키지이다. 모델 컴포넌트를 체크아웃하고 변화를 체크하기 위해서는 자신의 컴퓨터에 subversion client가 있어야 한다.

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

SolidGround : CSIRO에서 원래 제작한 EA를 위한 소프트웨어 확장으로서, ShapeChange를 수행하기 전, UML 모델을 테스트할 때 매우 유용하다. 이 소프트웨어는 더이상 CSIRO에서 관리하지 않는다. Windows 설치자(Solid_Ground_Setup.msi)는 XML Maintenance Group 저장소에 있다. 이 저장소에는 약간의 문서도 준비되어 있다. 

4.4.2 모델 설정

TC 211용 XML 스키마를 생성하기 위해서는 UML 모델을 구성할 때 특정한 UML 프로파일을 따라야 한다. 문제가 있으면 온라인 ShapeChange 문서를 참고하라. 핵심적인 스테레오타입 몇개를 소개하면 다음과 같다.

별도의 XML 네임스페이스로서 구현되는 각각의 모델 모듈은 별도의 UML 패키지로서 존재해야 하며, 이들 패키지의 스테레오타입은 <<Application Schema>>이어야 한다. Application Schema 패키지는 표 및 그림에 있는 태그가 존재해야 한다.

응용스키마 패키지는 반드시 하나이상의 하위 패키지를 가져야 하며, 이들 각각은 별도의 xml 스키마 파일에서 구현된다. 명확성을 위하여, 이들에게 스테레오타입 <<Leaf>>를 부여할 수 있으나. 이는 요구사항이 아니다.

응용스키마 수준에서 하나의 XML 스키마 파일이 생성된다. (이름은 해당 패키지의 xsdDocument 태그로 지정함(위의 예에서는 cit.xsd) 이 스키마파일은 <xsd:include>요소를 사용하여, 응용스키마 패키지 내에 있는 하위 패키지에서 생성된 스키마 파일을 include시킨다. 별도 분리된 스키마 파일을 원하는 경우(추천됨), 응용스키마 패키지내의 패키지에 xsdDocument 및 xsdEncodingRule 태그가 있어야 한다. 참고로 xsdDocument 경로는 <xsd:include> 경로가 간단해지도록, 최상위 xsd의 문서 경로와 일치하는 것이 좋다. (자세한 내용은 아래의 후처리를 참고)

UML 클래스 속성을 위한 태그

UML 클래스의 속성 및 탐색가능한 연관역할은 sequenceNumber 태그를 가지는 것이 좋으며, 이때 일련번호는 개별 UML 클래스 범위내에서 고유해야 한다. 일련번호는 필수가 아니며, 없을 경우 ShapeChange에서 자동생성한다. 존재하지 않을 경우, 특질을 위한 XML 요소는 클래스에 나타난 순서를 따르지만, 클래스에 다른 클래스로의 연관이 존재할 경우, 생성된 XML 스키마내에서의 이러한 요소의 순서는 예측불가능하다. 일련번호 사이에 공백이 있어도 무방하며, 속성이나 연관이 많고 나중에 새로운 속성이 추가되거나 순서나 변경될 가능성이 있는 경우 이런 공백이 도움이 될 수 있다.

패키지 간의 연결

EA 모델에서 다른 TC 211 응용스키마의 클래스는 반드시 EA 인터페이스를 사용하여, 해당 클래스에 대한 링크로서 포함해야 한다. 클래스명을 직접입력하면 필요한 내부 링크가 만들어지지 않는다. 이들 링크가 있으면 EA에서 의존성(dependency) 다이어그램을 자동 생성하고, UML-XL 프로세서로 생성할 때, 필요한 네임스페이스를 xml 스키마로 가져온다.

4.4.3 스키마 파일의 구조

결과 스키마는 여러 ISO 스키마를 위한 디렉토리구조로서 불러진다.(아래그림) 다른 모델에서 import 또는 하나의 모델의 여러 부분을 구현하는 스키마를 include하는 경로는 이 디렉토리 구조를 따른다. 최상위 폴더에는 각각의 TC211 표준을 위한 폴더가 있다.(ISO19115, ISO19110등) 이들 폴더에는 모델에서 정의된 각각의 xml 네임스페이스를 위한 하위폴더가 있는데, 네임스페이스 약어가 폴더명으로 사용된다. 다음 수준의 하위폴더는 각 네임스페이스 구현을 위한 버전 번호로 이름이 부여되며, 실제 스키마 파일은 해당 스키마를 위한 버전번호 폴더 내에 존재한다.

스키마는 'xsdLocation' 태그값에서 지정한 구조로 불러들여지게 된다. 이 태그값은 생성된 스키마가 저장될 위치에 대한 경로를 제공한다. 경로 위치는 ShapeChange가 수행된 최상위 디렉토리에 대한 상대경로가 된다.

4.4.4 작업 순서

==

원문 : https://github.com/ISO-TC211/UML-Best-Practices/wiki

국가공간정보포털 지식공간의 KSDI 표준체계 문서에는 총 23개의 기술기준이 등록되어 있다. 이중 공간정보 작성 및 제작관련 기술기준은 18개, 측량관련 기술기준은 13개, 기타 업무지침이 6개로 분류되어 있다. 측량의 결과도 실질적으로 공간정보라고 할 수 있으므로, 사실상 여기에 등록되어 있는 기술기준은 대부분 공간정보 제작에 관한 기술기준이라고 할 수 있을 것이다.

하지만, 이들 기술기준은 "공간정보표준에 적합한 기술기준"은 아니다.  국가공간정보 기본법 제23조(표준 등의 준수의무)에는 "공간정보체계의 구축ㆍ관리ㆍ활용 및 공간정보의 유통에 있어 이 법에서 정하는 기술기준과 다른 법률에서 정하는 표준을 따라야 한다."고 규정이 되어 있다. 이 규정만 보면 기술기준을 따라 작업을 하면 표준에 적합한 데이터가 생산될 것처럼 보이지만, 현재의 기술기준은 표준과 거리가 멀고, 현재 생산되고 있는 데이터도 대부분 표준에 적합하지 않다.

정부 및 지방자치 단체는 규정에 따라 일한다. 좀 극단적으로 이야기해서 규정에 어긋나면 아무것도 할 수 없는 것이 규정이다. 따라서 국가공간정보 기본법에서 표준을 지키라고 되어 있지만, 규정에 명시되어 있지 않으면 아무 것도 할 수 있는 것이 없다. 반대로 이야기하면, 일상 업무에서 표준에 적합한 데이터가 생산되기 위해서는, 기술기준을 따라 작업을 하면 자연스럽게 표준에 부합하도록 규정을 개정해야 한다는 것이다.

기술기준을 개정할 때 유의할 점이 있다. 제품 규격과 제작 방법을 구분해야 한다는 것이다. 우리나라 공간정보 관련 기술기준, 즉 각종 작업규정에는 대부분 데이터 제품에 대한 규격(중의 일부)과 제작 방법이 함께 규정되어 있다. 하지만, KS X ISO로 대표되는 공간정보 표준에는 제품의 규격에 관한 표준만 존재한다.

제품 규격이란 해당 제품 그 자체에 대한 규격을 말한다. 즉, 제품에 어떠한 지형지물이, 어떠한 구조로 만들어지며, 각각의 지형지물의 품질은 어떠하고 어떻게 평가해야 하는지, 생산되는 결과물과 함께 제공되어야 하는 메타데이터에는 어떤 것이 담기는지, 어떤 포맷으로 배포되는지 등, 제품을 생산하고 배포할 때까지 전 과정에 대한 기준이다. 

제품 규격은 KS X ISO 19131 "데이터제품 사양서"에 정의되어 있다. 제작하는 데이터 제품의 종류별로 이 표준에 따라 데이터 규격을 만들고, 이를 기술기준으로 등록해야 한다.  예를 들면, "항공사진측량 작업규정"이 아닌 "1/5,000 수치지형도 제품규격서",  "토지피복지도 작성지침"이 아닌 "토지피복지도 제품규격서", "수치지도 수정용 건설공사 준공도면 작성에 관한 지침"이 아닌 "건설공사 준공도면 제품규격서"가 기술기준으로 등록되어야 한다.

제품 규격이 정해지면 제작 방법은 다양할 수 있다. 예를 들어 1/5,000 수치지형도를 제작할 때, 현재는 대부분 항공사진 측량으로 제작되고 있으나, 적절한 고해상도 위성영상이 있다면 이를 활용할 수도 있고, 드론을 날려서 1/1,000 급의 대축척 지도를 제작한 후 이를 축소편집하여 제작할 수도 있다. 항공 LIDAR 스캐너를 이용해서 제작할 수도, 지상에서 GPS나 토털스테이션을 사용하여 제작할 수도 있다. 제품의 규격을 만족시킬 수 있다면 어떤 방법도 사용할 수 있도록 열어두는 것이 국제적인 추세이다. 이렇게 되어야만 새로운 기술이나 장비가 개발되더라도 유연하게 대처할 수 있다.

제작 방법은 "표준 작업 매뉴얼" 형태로 제작해야 한다. 예를 들어, 항공사진 측량 표준 작업 매뉴얼, 드론 사진측량 표준 작업 매뉴얼, LIDAR 측량 표준 작업 매뉴얼, GPS 측량 작업 매뉴얼 등을 만든다. 각각의 매뉴얼에서는 필요한 최소한의 방법론만을 제시하고, 작업기관에서는 작업의 성격에 따라 어떤 작업방법을 사용할지 알아서 결정할 수 있어야 한다. 대규모 건설공사의 경우, 시공하는 업체는 국가에서 정한 표준시방서와, 전문기관이 정한 전문시방서를 참고로 하여, 대상 공구에 적합한 공종을 선택하는 방식으로 자체적으로 시공 시방서를 작성한다. 공간정보 제작방법도 이러한 방식으로 표준 작업 매뉴얼을 참고하는 방식이 보편화되어야 한다.

작업자가 제작방법을 마음대로 선택한다고 하면 품질을 어떻게 보장할 수 있을지 우려를 할 수 있다. 하지만, 제품 규격서에는 데이터 제품에 포함된 각각의 지형지물에 대한 품질요소, 그리고 샘플링 방법을 포함한 품질 평가방법 등이 모두 기술되어 있으므로, 그 방법에 따라 품질을 평가할 수 있다. 작업기관에서도 자체적으로 품질을 평가해 볼 수도 있고, 품질평가원 등의 제3의 독립기관이나 발주기관에서도 동일한 방법으로 품질을 평가할 수 있다. 

제4차 산업혁명은 데이터를 기반으로 한다고 이야기한다. 이 데이터는 표준에 의해 제작된, 컴퓨터가 이해할 수 있고 자동처리될 수 있는 일관성 있는 데이터를 말한다. 이를 위해서는 모든 제품 제작이 데이터 제품 규격서를 기반으로 작성되고, 누구나 동일하게 이해하고 참조할 수 있는 구조가 되어야 한다. 공간정보가 실질적으로 제4차 산업혁명의 기반이 될 수 있기를 희망한다. 

====

이 글은 원래 공간정보표준 전담기관인 국토정보공사의 의뢰를 받아, 공간정보표준 뉴스레터 2019년 9월호에 실린 글입니다. 아래는 뉴스레터를 캡처한 것입니다.

민, 푸른하늘

INSPIRE 데이터 사양은 INSPIRE에 사용되는 다양한 주제의 공간데이터를 동일한 방법으로 정의하고 서술하기 위한 기준입니다. 데이터 사양에 따라 제작된 데이터는 어떠한 목적으로든 쉽게 교환할 수 있으며, 다른 데이터와도 쉽게 결합하여 사용할 수 있습니다. INSPIRE 의 가장 큰 목표는 "다양한 응용에서 끊김없이 사용할 수 있는 일관성 있는 데이터를 생산하는 것, 즉 데이터 상호 운영성"입니다. 이 목표를 달성하기 위한 가장 핵심이 데이터 사양이라고 할 수 있습니다.

참고로 INSPIRE 의 데이터 사양(data Specification)은 ISO 19131(데이터 제품 사양: Data product specification)에 기초하고 있습니다. 약간은 차이가 있을 수 있지만, 거의 대부분 비슷하다고 생각해도 됩니다. 다만, 제가 이제까지 본 데이터 제품 사양서는 대부분 꼭 필요한 내용만 담고 있어서 내용이 함축적이고 양이 많지 않음에 비해서, INSPIRE의 제품 사양은 해당 데이터에 관련된 내용을 모두 담고 있어, 다른 문서를 참조할 필요가 없습니다. 대신 양은 아주 방대합니다.

기술적 상호 운영성보다 더 중요한 것이 의미론적 상호운영성입니다. 의미론적 상호운영성에서는 데이터의 내용을 동일한 방식으로 이해될 수 있어야 한다는 의미입니다. 이를 위해서는 먼저 사용하는 용어, 개념 등의 통일이 중요합니다. 예를 들어 동일한 도로라고 해도 바라보는 입장, 즉 교통의 관점인가 유지관리의 관점인가에 따라 다르게 볼 수 있다는 것입니다. 특히 유럽의 경우엔 수많은 나라와 기관들이 얽혀 있기 때문에 이러한 개념-개념이 가리키는 실제 대상- 이를 가리키는 용어의 삼박자가 일치하는 것이 매우 중요합니다.

의미론적 상호 운영성의 핵심은 구조적/스키마 일관성입니다. 예를 들어 도로를 정의한다고 했을 때 한쪽에서는 도로를 면형 데이터로 구성하고 다른 쪽에서는 노드-링크로 구성하였다면 이 두 데이터를 서로 교환해서 사용하는 것은 거의 불가능할 것입니다. 어느쪽에서는 객체로 구성한 것을 다른 쪽에서는 속성으로 정의한다든지, 어느 쪽에서는 집합 연관관계를 구성하였는데, 다른 쪽에서는 이런 연관관계를 구성하지 않았다면, 데이터를 투명하게 상호 교환하기는 거의 불가능해집니다. 그때마다 사람이 개입해서 정확하게 구성되었는지 확인해야 하니까요. 이러한 중간 확인 과정없이 모두 자동으로 처리하고자 하는 것이 결국 데이터 상호 운영성 그 자체라고 할 수 있습니다.

아래 그림은 제가 "공간정보 유통과 표준에 대하여" 라는 글에서 동일한 도로에 대해 각기 다른 스키마를 채택한 예를 든 그림입니다. 이 상태 그대로는 데이터의 호환은 거의 불가능합니다. 이처럼 각기 다른 스키마를 가지고 있는 현실에서 어떻게 일관성을 확보할 것인가하는 것이 의미론적 상호 운영성의 핵심이라고 볼 수 있습니다.

이러한 방식으로 데이터를 모두 투명하게 가져다 쓰는 가장 쉬운 방법은 모두 동일한 구조, 동일한 시스템을 사용하는 방법일 것입니다. 물론 한개의 부서라면 가능하고 실제로도 그렇게 운영됩니다. 하지만, 조금만 범위를 넓혀도, 예를 들어 옆 부서간에도 사용하는 시스템이 다를 수 있고, 데이터를 바라보는 관점과 구조가 다를 수 있습니다. 지자체 전체로 보았을 때, 국가 전체로 보았을 때는 그 경우의 수가 끝도 없겠죠.

이를 해소하는 방법은 "공통 상호 도메인 모델"을 채택하는 것입니다. 기존의 시스템은 각각 고유의 내부 모델과 데이터를 그대로 유지하되, 이 공통 도메인 모델과 교환할 수 있는 방법만 고려하면 됩니다. 

아래는 제가  예전에 올린 "공간정보 유통과 표준에 대하여"라는 글에 올렸던 그림(원 소스는 ISO 19109 응용스키마)입니다.  이 그림에서 공통 응용스키마라고  표현한 것이 바로 INSPIRE에서 말하는 "공통 상호 도메인 모델"입니다. 이 그림에서는 시스템이 두개만 표현되어 있는데, 이러한 방식을 적용하면 아무리 많은 시스템이 있어도 동일한 방식으로, 모두 똑같은 의미로 데이터의 상호 운영성이 확보 될 수 있습니다.

아래는 INSPIRE에서 구축중인 34가지 공통 데이터 레이어입니다.

INSPIRE 에서는 데이터의 상호 운영성을 위하여, 이들 각각에 대하여 데이터 사양을 구축했습니다.  아래는 그중 몇개만 정리한 것입니다.

Annex I - 

• Coordinate reference systems (좌표계)
• Geographical grid systems (그리드 체계)
• Geographical names (지명)
• Administrative Units (행정구역 단위)
  

Annex II

• Elevation (고도)
• Land Cover (토지 피복)

Annex III

• Statistical Units (통계 구역)
• Buildings (건물)

예를 들어 아래의 PDF 파일은 건물(III.2)에 관한 데이터 사양입니다. 

inspire_dataspecification_bu_v3.0.pdf

아래는 이 데이터 사양에 들어 있는 3 가지 응용스키마중 한가지인 "Buildings 2D" 응용스키마 입니다. 보시는 것처럼 스테레오타입이 <<featureType>> 인 클래스가 총 6가지 뿐이 없습니다. 

다른 응용스키마도 이와 비슷하기 때문에 공통 데이터 모델(응용스키마) 자체만 봤을 때는 그다지 복잡할 게 없어 보입니다. 그럼에도 이 데이터 사양은 311쪽이나 됩니다. 읽어보면 정말 내용도 방대합니다. 여기에는 배경 정보, 유스케이스, 상위 실행규칙에 관한 내용 등등... 모든 것이 포함되어 있기 때문입니다. 한마디로, 건물에 관한 공통 데이터 모델에 부합하는 데이터를 만들고자 할 경우, 이 문서만 보면(다른 문서를 참고하지 않아도. 심지어는 INSPIRE 실행 규칙(IR)을 읽어 볼 필요 없이) 모든 필요한 내용이 들어 있습니다. 

===

INSPIRE의 34개 레이어 별로. 위와 같은 데이터 사양이 각각 정의되어 있습니다. 그냥 모든 문서가 300쪽이라고 가정하면 모든 문서는 거의 10,000 쪽에 달합니다.

문제는 이렇게 방대한 문서를 어떻게 하면 모든 분야에서 일관성 있게 작성할까 하는 것입니다. 각 분야의 전문가별로 그냥 각자 데이터 사양을 만들면, 각기의 관점에 따라 형식도 다르고 내용도 문서가 만들어질 것입니다. 어떤 사람은 자세하게 작성하고 어떤 사람은 압축하여 기술할 수도 있습니다. 심지어는 동일한 내용에 대해 다르게 기술할 수도 있을 것입니다.

INSPIRE 에서는 그래서 각 Working group 별로 데이터 사양을 제작하기 전에, 먼저 데이터 사양을 위한 모델링 프레임워크를 만들었습니다. 아래 그림에서 빨간 사각형으로 쳐둔 부분이 바로 이 모델링 프레임워크입니다. 이를 작성한 다음 해에는 가장 핵심 주제인 annex I의 9 개 레이어에 대해 데이터 사양을 작성하고, 2012년 부터 나머지 25가지 레이어의 데이터 사양을 제작했음을 알 수 있습니다.

여기에서 모델링 프레임워크라고 부르는 것은 아래와 같은 기술지침(technical guideline)을 말합니다. 이중에서 2.5 ~2.7이 가장 중요한 문서입니다.

• D 2.5 Generic Conceptual Model (범용 개념 모델)
• D 2.6 Methodology for the development fo data specification (데이터 사양 개발 방법론) 
• D 2.7 Guidelines for the encoding of spatial data (인코딩 가이드라인)
• D.2.10.x 공통 데이터 모델 --- 34개 레이어별 사양서
• D.2.9 관측 및 측정 가이드라인

아래 그림은 범용개념 모델(generic conceptual model)이 어떤 것을 의미하는지를 나타낸 것입니다. 가운데에 빨간 네모 박스를 해둔 부분이 범용 개념 모델로, 이 모델을 기반으로 각각의 데이터 사양(맨위)이 만들어 졌음을 볼 수 있습니다. 그리고 범용 개념 모델은 기존의 ISO/OGC 등의 기반 표준을 기준으로 만들어 졌다는 것을 볼 수 있습니다. 

즉, INSPIRE에서는 국제 표준을 그대로 채택한 것이 아니라, 그중에서 자신들이 사용할 것만 뽑고, 정리를 해서 "범용 개념 모델(Generic Conceptual Model)"이라는 것을 만들고, 이것을 기초해서 각각의 레이어별로 데이터 사양을 제작했으며, 이 데이터 사양을 기준으로 데이터를 제작하고 교환한다는 것입니다. 

일본의 경우에는 ISO 19100 시리즈 표준에서 자신들이 필요한 것들만 뽑아서 일본지리정보표준 프로파일(JPGIS : Japan Profile for Geographic Information Standards)를 만들고, 이를 모든 데이터 제작, 유통의 기준으로 삼고 있습니다. 당연히 일본에서도 JPGIS를 기준으로 데이터 제품 사양서를 만들고, 제품 사양서를 기준으로 데이터를 제작 유통하도록 규정되어 있습니다. INSPIRE 의 범용 개념 모델과 JPGIS가 일대일로 대응할 수는 없겠지만, 개념적으로는 동등한 수준이라고 볼 수 있을 것 같습니다.

INSPIRE 범용 개념 모델(GCM:Generic Conceptual Model)

GCM은 ISO 19100 시리즈를 기반으로 한 데이터 모델링 원칙입니다. ISO 19109에는 일반 지형지물 모델(GFM: General Feature Model)이 정의되어 있습니다. 지형지물(클래스)와 속성, 연관관계 등이 서로 어떻게 연결되는지 등을 정의한 메타 모델입니다. 이름상으로는 GCM과 GFM이 유사한 부분이 있을 것 같지만, GCM은 다음과 같은 내용을 담고 있어서, GFM 과는 완전히 다릅니다. (GFM도 포괄하고 있습니다.)

- 공통 용어 및 기반
- 데이터 사양 생산을 위한 요구사항과 권고사항
- 응용스키마에서 사용되는 기본 유형
- ID, 범용 네트워크 모델(GNM: Generic Network Model), 지명사전(gazetteer)를 포함한 공통 개념

아래는 GCM에 포함된 내용들입니다. 한마디로 GCM은 모든 데이터 사양을 위한 최적의 모델링 원칙으로서, 이를 따르면 일관성있는 데이터 사양을 만들 수 있습니다.

(A) INSPIRE 원칙(INSPIRE principles)
    - 공간데이터는 가장 적절한 수준에 보관하고 접근 가능하게 하고, 관리해야 한다.
    - 여러 관련자의 다양한 자료로 부터 공간데이터를 일관성있게 결합하고, 여러 사용자및 응용에서 공유할 수 있어야 한다.
   - 어떤 한 수준의 공공기관이 수집한 공간 데이터는, 다른 공공기간 관에도 공유할 수 있어야 한다.

(B) 용어(Termiology)
   - 용어를 참조할 때, 용어집을 통해 일관성 있는 언어를 사용해야 한다.
   - ESDI에서는 공통 용어를 만들어야 한다.

(C) 참조 모델(reference model)
   - 기술적 파트(정보 모델링 등)에 대한 프레임워크

(D) 응용스키마와 지형지물 목록에 대한 규칙(Rules for application schemas and feature catalugues)
   - 지형지물 목록에서는 공간 객체의 유형과 특성을 정의한다.
   - 공간 데이터셋의 완전한 내용 및 구조는 공식 개념스키마언어(UML)로 표현한 응용스키마로 정의

(E) 공간적 측면 및 시간적 측면(Spatial and temporal aspects)
   - 공간 객체의 공간/시간적 특성을 기술하는 개념 스키마
     - 공간 기하 및 위상/시간 기하 및 위상/커버리지 함수

(F) 다중언어 및 문화적 적응(Multi-lingual text and cultural adaptability)
   - 지형지물 목록, 지형지물 개념 사잔, 정의 및 지리적 명칭, 속성/연관 및 열거형/코드리스트 등은 다중언어로 기술한다.
   - 응용스키마는 다중 언어를 사용하지 않는다.

(G) 좌표 참조(coordiante referencing)
    - 공간/시간 참조체계, 측정 단위, 좌표 변환 매개변수, 유럽 지리 그리드(European geographical grids)

(H) 객체 참조 모델링(Object Reference Modelling)
   - 정보를 어떻게 기존의 공간 객체에 참조할 것인가. (좌표로 참조하는 게 아니라, 기본 지형지물 공간 객체를 통해 참조함)

(I) 데이터 변환 모델(Data translation Model)
   - 국가/지역 응용스키마를 INSPIRE 응용 스키마로 변환 및 그 반대 변환. 변환에는 데이터 변환과 질의 변환이 있음

(J) 묘화 모델(Portrayal Model)
   - 데이터 사양에 부합하는 데이터에 대한 묘화 규칙 모델. 표준화된 묘화 목록의 사용

(K) 식별자 관리(Identification Management)
   - Annex I/II에 있는 공간 객체는 객체 식별자를 가져야 함. 모호함이 없이 객체를 식별할 수 있는 유일 객체 식별자의 역할 및 성격을 정의함
   - 필요시 Annex III의 레이더도 유일 객체 식별자를 지원할 수 있음

(L) 등록물 및 등록소(Registers and registries)
   - 좌표계, 측정 단위, 코드 목록, 지형지물 개념 사전, 식별자 네임스페이스, 지형지물 목록, 응용 스키마 등을 등록할 수 있는 등록소(register) 필요
   - 등록소는 등록물 서비스(registry service)를 통해 접근할 수 있음
   - 데이터에 대한 메타 데이터는 별도의 카탈로그 서비스(catalogue service)를 통해 제공됨

(M) 메타데이터(Metadata)
   - 발견/평가/사용을 위한 메타데이터의 정의

(N) 유지관리(maintenance)
   - 변화된 것만 갱신함, 객체의 버저닝 지원, 공간객체 라이프 사이클 규칙

(O) 품질(Quality)
   - 각각의 공간 데이터 셋의 품질 수준 공개에 필요한 조언
   - 각각의 공간 데이터셋에 대한 수용가능한 품질 수준, 각각의 데이터셋에서 이 수준을 만족하는 방법 등의 모범 사례를 제공함

(P) 데이터 전달(Data Transfer)
   - 공간객체의 인코딩은 모델에 따라야 함. 즉 UML 응용스키마로 완전히 결정됨
   - 웹 서비스를 구현하는 네트웍 서비스를 지원하기 위해 공간객체는 GML로 인코딩되어야 함
   - 커버리지 데이터는 기존의 인코딩을 사용해야 함(예 정사영상)

(Q)  데이터간의 일관성(Consistency between data)
   - 국경, 주제, 분야, 해상도를 뛰어넘어 일관성이 있어야 함

(R) 다중 표현(Multiple representation)
   - 시간과 공간을 통한 합성,
   - 해상도간의 합성

(S) 데이터 획득(Data Capturing)
   - 주어진 공간 객체에 대한 데이터 사양 고유의 입력 기준)예, 호수는 2ha를 넘을 것, 도로는 European Road Network의 일부일 것 등

(T) 부합성(Conformance)
   - 어떤 데이터가 데이터 사양에 부합하는지를 시험하는 방법. 각각의 데이터 사양에 지정된 부합성 테스트를 적용해야 함

INSPIRE 데이터 사양 개발 방법

INSPIRE 기술 지침 2.6에서는 데이터 사양 개발 방법론(Methodology for the development fo data specification) 을 다루고 있습니다. 여기에서는 데이터 사양 문서에는 이런 이런 내용을 넣어야 한다는 것보다 훨씬 포괄적인 내용, 즉, 어떻게 사용자의 요구를 조사, 분석하여 데이터 사양에 담아야 할지를 담고 있습니다.

간단히 정리하자면, 먼저 기존의 정책자료, 보고서 설문조사 등을 통해 유스케이스를 개발하고, 현재 존재하는 데이터 등의 상황을 분석한뒤 이를 비교하여 차이를 분석하여 데이터 사양을 개발한 뒤 비용 편익 분석 등을 통해 반복한다는 내용입니다. 일반 시스템 개발에서 사용하는 방법론과 그다지 다른 것 같지는 않네요.

어쨌든... 이런 과정을 통해 작성되는 데이터 모델은, 너무 간단해서도 사용자 요구사항을 만족시킬 수 없고, 너무 복잡해지면 구현하기 힘들고 비용이 과다해 지므로, 적절히 균형을 유지해야 한다는 점을 강조하고 있습니다.

===

이상입니다. 이 글은 INSPIRE 데이터 사양에 관한 교육자료를 보고 마음대로 편집한 것입니다.

INSPIRE 지침(Directive)은 유럽연합 의회(Paliament) 및 각료 이사회(Council)에서, 유럽의 환경관련 정책에 사용되는 공간데이터를 효율적으로 공유하고자 하는 목적으로 만들어졌습니다. 이 지침은 2007년 5월 15일부터 효력을 발생하였으며, 2021년 목표로  실행중에 있습니다.

INSPIRE 지침의 핵심은 데이터/서비스의 상호운영성입니다. 이를 위하여 다음과 같은 5가지 비전을 제시하고 있습니다. 한마디로 줄이자면, 모든 관련 데이터를 일관성있게 작성하고, 관리하고, 공유하며, 평가할 수 있어야 한다고 할 수 있습니다.

• 데이터는 한번만 수집하고, 가장 효율적으로 관리할 수 있는 곳에서 유지관리해야 한다.
• 여러가지 자료들을 seamless하게 결합하고 공유할 수 있어야 한다.
• 정부 한 레벨에서 수집한 정보도, 모든 레벨에서 공유되어야 한다.
• 좋은 정책에 필요한 공간 데이터는 널리 활용될 수 있어야 한다.
• 쉽게 찾고, 목적에 맞는지 평가하는 것이 가능해야 한다.
  

INSPIRE 지침은 일종의 법률이라고 생각할 수 있습니다. 법률에는 시행령/시행규칙 등이 따르는 것처럼, INSPIRE 지침을 효율적으로 시행하기 위한 실행규칙(Implementing Rules)가 규정되어 있습니다. 이 실행규칙은 집행위원회(Commission)에서 제정하는 것으로, INSPIRE 지침과 실행규칙은 유럽연합 회원국들은 의무적으로 지켜야 합니다. 각각의 회원국이 지침과 실행규칙을 자국의 법률에 반영하는 것은 의무사항은 아니지만, 그래도 의무적으로 지켜야 하는 것입니다. 

INSPIRE 실행규칙은 아래와 같이 총 5개 분야에 대해 정의되어 있습니다. 이중 일부는 내용이 수정되거나 보완되어, 규칙 수는 전체 12개가 존재합니다. 

• 메타데이터(Metadata)
• 데이터셋/서비스 조율 및 상호운영성(Harmonization and Interoperability of Spatial data sets and services)
• 네트워크 서비스 (검색, 뷰, 다운로드, 전송, 미들웨어) (Network services(discovery, view, download, transform, middleware)
• 데이터 서비스 공유 (정책부분) (Data and Service sharing (policy)
• 모니터링 및 보고를 위한 협조 및 수단 (Coordination and measures for Monitoring & Reporting)

실행규칙까지는 어디까지나 "무엇을 해야한다"를 규정하는 것입니다. 구체적으로 "어떻게"해야 실행규칙에서 요구하고 있는 사항들을 달성하는지에 대해서는 기술 가이드라인(Technical Guidleine)이 만들어져 있습니다. 당연히 위의 5개 분야별로 구체적인 가이드라인이 만들어져 있습니다. (일부 분야는 아직도 작업중이라고 합니다.)

이러한 INSPIRE의 데이터/서비스 상호운영성을 확보하려면, 당연히 지오포털(GeoPortal)과 같은 컴퓨팅/네트워크 자원이 필요합니다. 유럽 연합 INSPIRE 지오포털은 http://inspire-geoportal.ec.europa.eu/입니다. 이곳에서 INSPIRE 데이터셋 검색/뷰/다운로드/변환 등의 서비스를 사용할 수 있습니다. 각 회원국에도 각자의 환경에 따라 지오포털을 설치할 수 있지만, 의무사항은 아닙니다. 하지만, 각회원국의 INSPIRE자원을 유럽 포털에 연결해야 하는 것은 의무사항입니다. 

INSPIRE 데이터는 총 34개의 레이어로 구성되어 있습니다. 이 내용은 Annex Theme의 정의와 범위(Definition of Annex Themes and Scope)" 정의되어 있는데 아래와 같습니다. 레이어만을 봤을 때는 우리나라의 기본공간정보에 환경관련 자료가 더 추가되어 있는 정도로 보입니다. 물론 축척(정보의 상세도)에 따라 다르겠지만, 이 정도 데이터면 거의 모든 공간 정보 분석에는 충분할 것 같습니다.

• Annex I (9)- 좌표계, 그리드, 지명, 행정단위, 주소, 지적, 교통네트워크, 수질, 보호구역
• Annex II (4) - 고도, 토지피복, 정사사진, 지질
• Annex III (21) - 통계구역, 건물, 토질, 토지이용, 건강/안전, 유틸리티 및 정부서비스, 환경 모니터링 시설, 생산 및 공업 시설, 농수산 시설 , 인구 분포, 지역관리/제한, 자연재해 위험구역, 대기 조건, 기상적 지리적 특징, 해양 지리적 특징, 바다 구역, 생물 지리 구역, 생태구역/바이오톱, 종의 분포, 에너지 자원, 광물 자원
  

모니터링 및 보고 (COMMISSION DECISION of 5 June 2009)

INSPIRE 실행규칙 5종 중에서, 비 기술적인 실행규칙이 두가지 종류가 있는데, 이 실행 규칙은 그 중 하나입니다. (다른 하나는 데이터 서비스 공유) 이 실행규칙을 위해서 다음과 같은 보조 문서들이 있습니다.

• 모니터링 및 보고를 위한 가이드 라인
• 모니터링 지표를 위한 템플릿, 보고를 위한 템플릿
• 모니터링과 보고를 위한 접근방법의 부합성 문서?

정책 시행에 있어 가장 중요한 것은 모니터링 및 보고입니다. 어떤 정책이 제대로 시행되는지 검사를 하지 않고 그냥 알아서 하도록 둔다면, 시행하는 사람도 그것을 취합하는 사람도 정확한 현 상황을 파악하기 힘들 것입니다. INSPIRE에서는 지속적으로 모니터링하고, 최소한 3년마다 한번씩 보고를 하며, 그 결과를 공개하도록 명시하고 있습니다. INSPIRE에 관계된 모든 사람들은 정보수집에 참여하여 정보를 제공해야 하며, 그 모니터링/보고 대상은 기본적으로 데이터셋 및 서비스입니다. 

검사하는 내용은 다음과 같습니다.

• DSi1 - 해당 데이셋이 존재하는가?
• DSi2 - 그 데이터셋은 INSPIRE에 부합하는가?

• MDi1 - 그 데이터셋에 대해 메타데이터가 존재하는가?
• MDi2 - 그 메타데이터는 INSPIRE에 부합하는가?

• NSi1 - 서비스에서 이 메타데이터에 접근할 수 있는가?
• MSi2 - 서비스에서 데이터셋에 접근할 수 있는가?
• MSi3 - 서비스를 사용할 수 있는가?
• MSi4 - 서비스가 INSPIRE에 부합하는가?

즉, 회원국은 자신이 제작하여 유럽 지오포털에 올리는 데이터 34종에 대해 각각 이러한 기준을 만족하는지 지속적으로 모니터링하여 보고한다는 뜻입니다. 

보고 양식은 아래와 같습니다. 어떤 나라인지는 표시되어 있지 않지만, 이 나라에서 Annex I에 속하는 데이터셋 9종(좌표계, 그리드, 지명...)은 메타데이터 항목의 첫번째 지표(MDi1)에 대해서 98개의 평가항목중 72개를 만족했으며, 두번째 지표(MDi2)에 대해서는 98개 항목중 26개만 만족했다는 뜻입니다. 

Annex I은 총 9개의 레이어로 구성되어 있는데, 실제 데이터셋은 98개이라고 되어 있어서 좀 이상해 보입니다만, 어쨋든 98개중 72개만 메타데이터가 존재하고, 그중에서 INSPIRE 지침에 부합하는 것은 27%에 불과하다는 뜻입니다. 

모니터링 및 보고는 2010년부터 시작하여, 매년 2개씩 보고서를 제출하고 있으며, 2013년 현재 18,138건의 데이터셋 및 7,088건의 서비스에 대해서 이러한 모니터링이 이루어지고 있다고 합니다.

데이터/서비스 공유(Commison Reglation No 268/2010)

데이터 서비스 공유에 관한 실행규칙도 비 기술적 실행규칙입니다. 이 실행규칙은 2010년 발효되었으며, 다음과 같은 보조 문서들이 있습니다.

• 가이드라인  : "각국의 데이터/서비스 공유 모범사례"에 관한 문서

이 실행규칙은 "관계기관 및 일반 사용자들에게 공간 데이터셋 및 서비스를 조화된 조건에 따라 제공"함을 목적으로 하고 있습니다. 다음은 이 실행규칙에서 정의된 사항중 일부입니다.

• 용역 등에 참여하는 계약자에게는 공간 데이터셋 및 서비스를 접근할 수 있도록 해야 한다.
• 데이터/서비스에 대해서 접근을 제한 할 수도 있지만, 반드시 공유를 제한하는 이유를 제시해야 하며, 접근하려면 어떤 조건이 만족되어 하는지를 알려야 한다.
• 합의나 계약을 할 경우, INSPIRE 지침 제3항에 있는 용어를 사용해야 한다.
• 반면 승인하지 않은 사용에 대해서는 엄격히 제한하여, 제3자는 INSPIRE 데이터셋/서비스를 다른 사람들에게 제공해서는 안된다.
• 이러한 데이터/서비스의 접근 가능성에 관한 정보는 반드시 메타데이터에 반영되어 있어야 한다.
• 평가 및 사용에 관한 정보는 필요시 제공해야 한다. 여기에는 사용시 비용도 포함될 수 있다.
• 문서 요청으로부터 20일 이내에 데이터 셋 및 서비스를 접근할 수 있도록 해야 한다.

이 실행규칙의 가이드라인 문서인 "각국의 데이터/서비스 공유 모범사례"에는 협조체계, 계약 방법, 투명성, 라이센스, 비용 부과 방법, 공개적인 접근, 비상시 사용, 제3자 데이터 등에 대해 여러가지 사례가 들어 있다고 합니다.

메타데이터 (COMMISSION REGULATION (EC) No 1205/2008)

메타데이터는 기술적 INSPIRE 실행규칙 중 하나입니다. (나머지는 네트워크 서비스, 데이터 사양 입니다.) 메터데이터에 관한 실행규칙은 2008년 발효되어, 다른 어떤 실행규칙보다 빨리 제정되었습니다. 그만큼 중요하다는 반증이라고 생각합니다. 이 실행규칙의 보조문서는 다음과 같습니다. 

• 정오표
• ISO 19115 및 ISO 19119에 기반한 가이드라인
• 실행규칙 개발 절차에 관한 보고서

메타데이터는 공간 데이터 또는 서비스에 담겨 있는 내용을 요약한 것으로, 어떤 데이터가 들어 있는지, 어떻게 사용할 수 있는지 등등에 관한 내용이 들어 있습니다. 사용자는 메타데이터를 통해 자신이 원하는 목적에 맞는 데이터를 찾을 수 있습니다.

메타데이터 실행규칙에는 다음과 같은 내용이 정의되어 있습니다.

• ISO 표준에 정의된 필수 요소 및 추가 요소
• 가이드 라인 변경에 따른 동적인 측면
• 메타데이터 요소의 조건 및 다중성
• 각각의 메타데이터에 대한 값 정의역

아래는 데이터 셋에 대한 메타데이터 중 일부를 추린 것입니다.

아래는 서비스에 관한 메타데이터입니다. 일부는 데이터셋에 대한 메타데이터와 동일한 것들도 있지만, 서비스에만 적용되는 항목들도 존재합니다.

2014년 초까지 28만 5천개 정도의 메타데이터가 등록되어 있고, 유럽 지오포털을 통해 검색할 수 있다고 합니다. http://inspire-geoportal.ec.europa.eu/proxybrowser/ 에 들어가보시면 제가 글을 쓰는 현재, 총 51만건이 등록되어 있다고 나오네요.

네트워크 서비스 (COMMISSION REGULATION (EC) No 976/2009
                       Commission Regulation (EU) No 1088/2010 )

네트워크 서비스에 관한 실행규칙은 기술적 실행규칙중 하나로서, INSPIRE에 규정된 여러가지 서비스 (검색, 뷰 서비스가 중점)에 대한 내용입니다. 이 실행규칙에 대한 보조문서는 다음과 같습니다.

• INSPIRE Viewing 서비스 기술 가이드라인(2.0)
• Dicovery 서비스 가이드라인(2.0) - 
• SOAP Primary for View/Discovery 서비스
• Web Service Description Language를 사용한 view/discovery 서비스의 문서화에 대한 제안
• 기타 기술적 보고서
  

이 실행규칙은 서비스에 관한 기술적 규격이나 성능 기준 등을 정의함으로써, 상호운영성을 확보하는 것이 목적입니다. 최초 운영 능력(IOC, initial operating capability), 성능, 용량, 가용성, 반응시간, 서비스 요청, 발행, 수집, 레이어 등 다양한 부분에 대해 정의하는데, 특히 검색(Discovery)및 뷰(View)서비스에 관한 특정한 요구사항을 정의하고 있습니다.

예를 들어 Annex 1에는 서비스 품질에 대해 정의하는데, 검색서비스의 반응 시간은 3초 이내, GetMap 요청에 대한 반응시간(470kb)은 5초 이내이어야 하며, 동시접속은 각각 30, 20이상이라고 정의하고 있습니다.

Annex II는 검색서비스에 대한 내용으로서, 어떤 검색을 제공해야 하는지, 어떤 연산을 제공해야 하는지 등을 정의하고 있습니다. 제공해야 하는 연산은 다음과 같습니다.

• Get Discovery Metadata
• Discovery Metadata
• Publish Metadata
• Link Discovery Service

Annex III는 뷰서비스에 대한 내용으로서, 아래와 같은 연산이 제공되어야 한다고 정의하고 있습니다. 또한, 좌표계를 지원해야 하며, 영상 포맷은 적어도 PNG와 GIF를 지원해야 한다고 명시하고 있습니다.

• Get View Metadata
• Get Map
• Link View Servcie

==

네트워크 서비스에 관한 실행규칙은 이 외에도 한가지 종류가 더 있습니다. 바로 Commission Regulation (EU) No 1088/2010 로서, 여기에서는 다운로드 및 변환 서비스가 정의되어 있습니다. 이 실행규칙에 대한 보조문서는 다음과 같습니다.

• INSPIRE 스키마 변환 서비스에 관한 기술 가이드(초안)
• 스키마 변환 네트워크 서비스 - 최신 기술 분석
• INSPIRE 좌표변환 서비스 기술 가이드(초안)

마찬가지로 이들 서비스에 대해서도 성능, 반응시간, 용량, 가용성 등에 대한 최소 기준이 정의되어 있습니다. 예를 들어 성능 부분에서 Get Spatial Dataset 및 Get Spatial Object 연산의 경우, 30초 이내에 반응 해야 한다고 구체적으로 정의되어 있습니다. 

Annex II에는 다운로드 서비스에서 제공되어야 할 연산을 정의하고 있습니다.

• 연산
• Get Download Service Metadata
• Get Spatial Dataset
• Describe Spatial Data set
• Link Download Service
• 직접 접근 다운로드 연산
• Get Spatial Object
• Describe Spatial Object Type
• Get Spatial Object 연산을 위한 검색 기준
• URI, 핵심 속성 (예: 갱신 일), 지역, 주제 등

데이터 사양 개발(Commission Regulation (EU) No 1089/2010
                      Commission Regulation (EU) No 1312/2014)

제가 제일 관심있는 부분은 데이터 사양입니다. INSPIRE 데이터셋 또는 데이터셋 시리즈를 어떻게 만들지를 구체적으로 정의한 부분이기 때문입니다. 데이터 사양은 한마디로 설계도라고 할 수 있습니다. 제작 및 평가의 기준이 된다고 할 수 있죠. 다만 이 실행 규칙은 "공간 데이터셋 및 서비스의 상호운영성"을 위한 실행 규칙이라고 되어 있습니다. 서비스에 관한 내용이 어떤 것인지 감은 안잡힙니다만... 아래는 이 실행규칙에 대한 보조 문서들입니다. 이중에서 2.3부터 2.7까지는 데이터사양을 만드는 방법에 대한 기준이며, 2.8 이하에서는 각각의 주제에 대한 구체적인 사양이 있습니다.

• D 2.3 Definition of Annex Themes and Scope(기본) 
• D 2.5 Generic Conceptual Model 
• D 2.6 사양 개발 방법론 
• D 2.7 인코딩 가이드라인 
• D 2.8.1.1 -... Annex I 주제에 대한 데이터 사양... 그 다음에 Annex II 등
  

2013년 현재까지 18000여건의 데이터셋이 공개되어 있는데, 아주 일부만이 데이터 사양에 부합된다고 말하고 있습니다. 기존의 데이터셋은 당연히 INSPIRE 제품사양 기준에 따라 변환되어야 합니다. 이러한 변환은 시간도 많이 걸리고 매우 복잡한 절차가 필요한데, (일부는 아얘 너무 사양과 거리가 멀어서 변환자체도 불가능하기도 하답니다.) "Data harmonization", "Precedures for data and metadata harmonisation", "Examples of data transformation" 등의 모듈을 사용하여 변환해야 하는 것 같습니다.

두번째 실행 규칙 1312/2014는 주로 서비스에 관한 규칙이라고 하는데, 자세한 내용은 없습니다.

INSPIRE에 대한 부합성

데이터 또는 서비스를 공개할 때 가장 중요한 것은 표준에 맞느냐 하는 것입니다. 하지만, 표준은 범위가 너무 넓다보니, 그냥 표준을 지켰느냐라고 하는 것은 별로 의미가 없습니다. 정말 표준을 지켰다고 하면 ISO 19100 시리즈의 모든 문서의 추상 시험 스위트를 하나씩 검사해서 모두 통과했다는 뜻이기 때문에, 사실상 불가능하기도 하고, 일부는 의미가 없을 수도 있습니다.

표준에 대한 부합성을 논의하려면, 구체적으로 지키고자 하는 내용을 프로파일(Profile)로 정하고, 이에 대한 부합성을 따지는 방향으로 이루어져야 합니다. INSPIRE에서도 당연히 이러한 방향으로 진행되고 있으며, 따라서 이 부분에서는 어떤 규정을 지켜야 하고, 어떻게 테스트를 해야 INSPIRE에 부합하다고 할 수 있는지 (표준을 지켰다고 할 수 있는지)를 규정하고 있습니다.

INSPIRE 부합성을 따지는 대상은 메타데이터, 네트워크 서비스 및 데이터셋입니다. 당연히 위에서 논의했던 내용에 대해서만 부합성을 따질 수 있는 것입니다.

부합성을 따지는 기준은 당연히 실행규칙(IR : Implementing Regulation)입니다. 이는 법적 기준으로서 반드시 지켜야 합니다. 그 구체적인 요구사항 및 시험 방법에 대해서는 기술 가이드라인(TG)에 추상시험 스위트(ATS : Abstract Test Suites)로 규정되어 있습니다. 실제 구현하는 사람들은 이 ATS를 실행가능 시험 스위트 (ETS : Executable Test Suites)로 구현하여 메타데이터/서비스/데이터셋에 대해서 시험해야 하는 것입니다. (일부는 수작업으로만 검사할 수 있는 것도 존재합니다) 이러한 부합성 테스트를 통과한 데이터에 대해서는 인증을 하게 되고요.

이러한 과정을 통해 INSPIRE에 대해 부합한 데이터가 있어야만 모든 INSPIRE 시스템이 원할하게 돌아갈 수 있게 됩니다. 예를 들어 데이터셋의 내용이 변경되었을 때, INSPIRE에 부합한 데이터셋이라면 사람의 개입없이도 자동으로 지오포털까지 변경될 수 있는 것입니다.

예를 들어 INSPIRE 메타데이터에 대한 검증기는 아래에 있습니다. 누구든 자신이 작성한 메타데이터가 INSPIRE에 부합하는지를 확인하려면 이 데이터 검증기에 돌려보면 됩니다.

• http://inspire-geoportal.ec.europa.eu/validator2/
  

===

이 글은 이 자료를 제 나름대로 정리한 내용입니다.

민, 푸른하늘

INSPIRE 개요

INSPIRE 지침(Directive)의 목적은 유럽연합 환경 정책 및 환경에 영향을 미칠 수 있는 정책이나 활동을 위하여, 유럽연합 공간 데이터 인프라를 생성하기 위함이다. 이 유럽 공간 데이터 인프라를 사용하면, 공공 기관간의 환경 공간 정보의 공유를 촉진하고, 유럽내 공간 정보에 대한 공공 접근을 활성화하며, 여러 국가에 걸친 정책의 결정에 도움을 줄 수 있다. 

INSPIRE는 유럽 연합 회원국이 각자 제작, 운영하고 있는 공간 정보 인프라에 기초한다. INSPIRE 지침은 환경 응용에 필요한 34개의 공간 데이터 주제를 다루고 있다.

INSPIRE는 2007년 5월 15일에 시행되었으며, 여러가지 단계로 시행되어 2021년까지 완료될 예정이다.

아래의 동영상은 INSPIRE가 왜 필요하며, INSPIRED에서 다루는 공간 데이터의 유형에 대해 다루고 있다.

INSPIRE 정책의 배경

공공기관에서 사용되고 교환되고 있는 모든 정보는 상당한 부분이 특정한 위치를 참조하고 있다. 이러한 정보의 품질은 '공간 데이터'의 이용가능성에 따라 달라지며, 공간 데이터는 수집된후 (지리 참조되어) 위치에 연결된 후, 처리하여 정보를 생성한다. 대부분의 환경정보, 즉, 배출 측정, 생태 다양성 관측 또는 환경 품질 데이터 등은 공간적 성격을 가지고 있다. 

정책 관련 평가와 분석은 여러가지 환경 및 공간 데이터를 조합하여 이루어진다. 토지이용, 행정 경계, 표고, 수자원, 교통망, 생산시설, 보호 시설 등이 그러한 예이다. 기상, 지질, 토양 등의 지리 물리적 데이터는 또한, 인구 밀도나 건강과 안전에 관한 데이터 등과 같은 사회 경제적 데이터 뿐만 아니라, 환경 정책적 관점에서도 관련이 있다.

환경에 영향을 미치는 여러가지 주제적 환경적 법령 및 정책(농업, 교통, 에너지, 공간 개발 등)에 깔려 있는 프로그램과 조치는, 일반적으로 환경에 미치는 사회적 압력으로부터 발생하는 위험성 혹은 재난이 될 수 있는 자연 또는 인공적 위험의 완화가 필요하다. 

예를 들어, 대기의 질과 기상 조건에 관한 데이터를 교통, 공장 위치, 도시/농업의 공해 배출원, 역학 등과 연계하면, 대기 오염에 의해 건강에 미치는 영향을 평가할 수 있다. 이러한 데이터는 공해원인을 식별하고, 대기의 질에 영향을 미치는 정책에서 배출 경감 목표를 조정하는 등에 사용할 수 있다.

INSPIRE 지침의 준비과정(2001-2004)에서 수행된 수많은 사실 확인 및 공개 컨설팅을 통해, 환경에 영향을 미치는 환경 정책에 필요한 공간 데이터가 널리 사용되지 못하게 가로막는 중요한 장애 요인을 식별하였다. 예를 들어 지역에서 유럽을 대표하는 모든 분야의 공개 컨설팅 참여자중 97%는 다음과 같은 내용에 동의하였다.

1. 공간데이터가 빠지거나 불완전한 경우가 많다.
2. 사용 가능한 공간 데이터에 대한 설명(문서)가 불완전한 경우가 많다.
3. 공간 데이터셋을 다른 공간 데이터셋과 결합하기 힘든 경우가 많다.
4. 공간 데이터를 찾고 접근하고 사용하는 시스템이 별개로 작동되며, 호환되지 않는 경우가 많다.
5. 문화적, 제도적, 재정적, 법적 장애로 인해 기존 공간정보의 공유 및 재사용이 방해 혹은 지연된다.

INSPIRE 원칙

INSPIRE는 아래와 같은 여러가지 공통 원칙에 기초하고 있다.

1. 데이터는 단 한번만 수집되고, 가장 효율적으로 관리되는 곳에 저장되어야 한다.
2. 유럽 전역 여러 자료원의 공간 정보를 원할하게 결합하고, 많은 사용자 및 응용에 공유할 수 있어야 한다.
3. 한 레벨/축척에서 수집된 정보를 다른 모든 레벨/축척과 공유할 수 있어야 한다. 자세한 정보는 조사를 위해, 일반적 정보는 전략적 목적으로 활용할 수 있다.
4. 모든 레벨에서 원할한 가버넌스를 위해 필요한 공간 정보는 언제든지, 투명하게 제공되어야 한다.
5. 어떠한 공간 정보를 사용할 수 있는지, 어떻게 특정한 요구에 따라 사용할 수 있는지, 어떠한 조건으로 취득하고 사용할 수 있는지 등에 대해 쉽게 파악할 수 있어야 한다.

INSPIRE 규약

INSPIRE 지침은 2007년 4월 25일 공식 간행물에 발행되었고, 2007년 5월 15일 발효되었다.

Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)

(2007 3월 14일 유럽 의회 및 위원회 발의, EC내 공간정보를 위한 하부구조(INSPIRE) 설립을 위한 지침 2007/2/EC)

INSPIRE

실행 규칙

회원국의 공간데이터 인프라가 각각의 커뮤니티 및 경계를 넘어 상호 호환되고, 사용될 수 있도록 보증하기 위해서는 여러가지 특정 분야에서 공통 실행규칙(IR, Implementing Rules)의 채택이 필요하다. 이러한 실행 규칙은 위원회 명령(Commission Decision) 혹은 규칙(Regulation)으로 채택되었으며, 모든 구성원의 의무이다. 위원회는 이러한 규약을 채택하는 과정에서 규제 위원회(regulatory committee)의 도움을 받았다. 이 위원회는 회원국의 대표로 구성되며, 위원의 대표가 회장이다.(Comitology procedure)

메타데이터

데이터 사양

네트워크 서비스

데이터 및 서비스 공유

모니터링과 보고

INSPIRE 실행 규칙

회원국의 공간데이터 인프라가 각각의 커뮤니티 및 경계를 넘어 상호 호환되고, 사용될 수 있도록 보증하기 위해서는 여러가지 특정 분야에서 공통 실행규칙(IR, Implementing Rules)의 채택이 필요하다 

• 메타데이터
• 데이터 사양
• 네트워크 서비스
• 데이터 및 서비스 공유
• 공간 데이터 서비스
• 모니터링 및 보고

이들 실행 규칙은 위원회 결정 및 규약으로 채택되었으며, 모든 구성원의 의무이다. 

위원회는 이러한 규약을 채택하는 과정에서 규제 위원회(regulatory committee)의 도움을 받았다. 이 위원회는 회원국의 대표로 구성되며, 위원의 대표가 회장이다.(Comitology procedure)

INSPIRE 기술 지침

실행 규칙 외에도, 의무가 아닌 기술 지침 문서에는 상세한 실행 측면 및 기존 표준, 기술, 사례 등과의 관계를 기술하고 있다. 아래의 그림은 실행 규칙을 INSPIRE 규약과 이에 대응되는 기술 지침 문서간의 관계를 나타낸 것이다.

기술 지침 문서는 회원국이 위원회 규정(Commision Regulation)으로 기술된 실행규약(Implementing Rules)를 실행할 것인지를 정의한다. 기술 지침 문서는 의무가 아닌 기술적 요구사항을 포함할 수 있다. 회원국이 이 기술 지침에 부합하고자 선택할 경우, 이 기술적 요구사항을 반드시 만족시켜야 한다. 이 기술적 지침을 실행하면 INSPIRE 서비스의 상호운영성을 극대화시킬 수 있다.

기술 지침 문서의 유지관리는 INSPIRE 유지관리 및 실행 프레임 워크의 중요한 임무이다.

모든 기술 지침 문서는 여기에서 볼 수 있다.

INSPIRE 관계자

INSPIRE 코디네이션 팀(CT)

INSPIRE 코디네이션 팀은 DG Environement와 JRC(Joi8nt Research Center)의 유럽 위원회 직원 및 유럽 환경 위원회(EEA)의 직원으로 구성되어 있다. 이들의 임무는 INSPIRE의 실행 및 향후 발전을 조율하고, 다른 EU 정책과 협조하는 것이다.

DG Environement는 INSPIRE를 위한 전반적인 법적, 정책적 코디네이터로서 역할을 한다. 환경 정책에 관한 INSPIRE의 주요 목적하에, EEA에 대한 협력을 기반으로, DG Environment는 실행 프로그램을 위한 프레임 워크로서, INPIRE를 위한 환경적 주제적 정책 요구사항을 규정한다. DG Environement는 INSPIRE 유지관리 및 실행 그룹의 의장을 맡고 있다.

JRC(Joint Research Center)는 INSPIRE의 전반적인 기술적 코디네이터 역할을 한다. JRC는 INSPIRE를 위한 기술적 인프라의 실행가능성 및 혁신을 보장하며, 유럽 및 국제 연구그룹 간의 협력을 보증한다. JRC는 또한 INSPIRE의 목적을 위한 국제 표준화단체와의 공동작업을 주도 및 모니터링 하며, 기타 관련 국제 활동과의 기술적 조율에도 책임이 있다. JRC는 INSPIRE 유지관리 및 실행 그룹(MIG-T)의 기술 하부 그룹의 의장을 맡고 있다.

2013년 유럽 환경 위원회 (EEA, European Environmental Agency)는 모니터링과 보고와 관련된 업무를 수행하고 SEIS 및 INSPIRE 활동의 일부로 INSPIRE 하의 데이터/서비스 공유함으로써, EU 수준의 협조에 대한 참여를 늘렸다. EEA는 또한 잘 설치된 유럽 환경 정보 및 관측 네트워크(Eionet)을 통한 네트워킹 경험을 살려, INSPIRE를 다른 EU 수준의 활동과 통합을 강화하였다. 여기에는 환경적 경험하에 보고 및 정보 배포도 도함된다.

INSPIRE 위원회(IC)

INSPIRE 지침 22조에 따르면, 회원국 대표로 구성되는 INSPIRE 위원회(Committee)는 위원회(Commission)를 지원하고, 위원회(Commission)에서 제안되는 실행 규칙 도안에 대한 각자의 의견을 전달하는 데 도움을 주는 일반적인 임무를 부여받고 있다. 이러한 의견은 투표의 형태를 띈다.

국가 접촉선(NCP: National Contact Points)

INSPIRE 지침 19(1) 항에 따르면, 각 회원국은 반드시 접촉선을 지정해야 한다. 접촉선은 대부분 공공기관으로, INSPIRE에 관련하여, 위원회에 대한 접촉에 책임이 있다. 예를 들어 접촉선은 INSPRE 실행에 관한 정보를 각 국가에 제공해야 할 책임이 있으며, 회원국을 대표하여 위원회에 보고해야 한다.

국가 접촉선 목록

INSPIRE 유지관리 및 실행 그룹(MIG)

2013년, INSPIRE 국가 접촉선 대표로 구성되는 INSPIRE 유지관리 및 실행 그룹이라는 위원회 전문가 그룹을 설치하였다. MIG는 유럽 위원회(DG Environment와 JRC), EEA, EU 회원국 간의 공동활동을 조율하고, INSPIRE 지침의 유지관리 및 실행을 지원한다.

MIG는 기술적인면을 다루는 영구적인 하부그룹(MIG-T)가 있으며, 유리관리 및 실행 작업 프로그램(MIWP)에서 정의한 특정 활동에 초점을 맞춘 한시적 하부그룹을 설치할 수 있다.

MIG는 이해관계자 그룹으로부터 선정된 전문가 플에 의해 보환된다. 이 전문가 풀은 MIG 하부그룹이 특정 실행 및 유지관리 문제를 해결하기 위해 설치될 때 소환할 때 이용되지만, INSPIRE 실행 또는 유지관리 특정 측면에 관련하거나 관심있는 전문가에 접근할 수 있는 기회도 제공한다.

MIG 대표

MIG-T 대표

전문가 풀

INSPIRE 이해 관계자

INSPIRE 실행 계획 및 기술 지침 문서 및 유지관리 및 실행 프레임워크를 개발하기 위해서는 회원국의 이해 관련 기관으로부터의 전문가에 대한 참여 프로세스가 필요하다.

이해 관련 기관은 MIG 작업을 위한 전문가 추천을 의뢰받으며, MIG 및 하부그룹의 작업에 대한 입력 및 피드백을 제공한다. 이해 관련 기관의 전문가는 주제 클러스터 토론 플랫폼에서 실행 문제에 관한 토론도 할 수 있다.

참고 : 법적 프레임워크를 개발하는 동안, 이해 관련 기관은 법적 의무 기관(LMO)와 공간데이터 관심 커뮤니티로 구분되었다. 이러한 구분은 실행 단계에서는 구분하기 힘들기 때문에 그다지 고려하지 않고 있다.

공간데이터 관심 커뮤니티(SDIC: Spatial Data Interest Communities)

법적 의무기관(LMO: Legally Mandated Organisation)

교육 라이브러리

교육 교재

위원회 및 EEA 및 연구 프로젝트나 이해관계 기관에 생산된 다양한 교육 자원이 존재한다.

이러한 교육 코스의 선택은 공간지식베이스(GKB : Geospatial Knowledge Base) 교육 플랫폼에 만들어져 있다. GKB는 EC INSPIRE 팀과 ELISE 프로젝트에서 공동으로 위탁하고 있다. 이들 INSPIRE 교육 라이브러리는 무료이나, 등록이 필요하다.

INSPIRE 교육 교재를 위한 등록

이 라이브러리에 추가하고 싶은 교육 모듈이 있다면 제안을 제출하거나, 아래의 링크를 이용해 주세요.

교육 모듈 제안

새로운 교육 모듈 요청

INSPIRE를 위한 의미론적 지식

◎: 필수 ○: 선택

고급 기술 모듈

◎: 필수 ○: 선택

◎: 필수 ○: 선택

INSPIRE 용어집에는 INSPIRE 지침 및 INSPIRE 실행 규칙 문서 그리고 이 교육 모듈에서 사용되는 공통 용어에 대한 일반적인 용어 및 정의를 담고 있다.

===

https://inspire.ec.europa.eu/about-inspire/563

일본 국토지리원에서 공간정보 표준과 관련하여, 공공측량 시행시 공간정보 표준을 지키는 방법에 대해 설명한 글입니다.

간단히 요약하면, 측량계획기관(발주자)가 측량사업을 시행하고자할 때, 먼저 제작하고자하는 측량성과의 종류, 내용, 구조, 품질 등을 담은 제품사양서를 작성해야 합니다. 이를 공공측량시행계획서와 함께 국토지리원에 제출하여 승인을 받습니다. 

이때 제품사양서에는 여러가지 내용이 포함되므로, 이 사이트에는 여러가지 샘플을 제공함과 동시에, 제품사양서 편집툴도 제공합니다. 전형적인 측량작업인 경우에는 샘플을 편집하는 방법이 편하고(기준점 측량부터 응용측량까지 측량 종류별로 따로 샘플이 있습니다.), 독특한 측량작업이라면 처음부터 제품사양서를 만들어야 하는데, 이때 제품사양서 편집 툴을 사용합니다.

제품사양서는 측량사업을 발주시 필요한 여러가지 사업관련 서류중의 하나로 포함됩니다. 측량작업기관은 이 제품사양서를 기준으로 측량을 실시하고 그 품질을 평가하여 메타데이터와 함께 측량 계획기관에 제출합니다. 이때 측량성과는 GML 로 제출합니다. 공간정보 표준에서 데이터 교환에는 GML 포맷을 사용하는 것이 표준으로 되었기 때문입니다.

품질 평가의 경우, 각각의 측량작업 별로 [품질요구 및 평가]에 관한 샘플이 있으므로, 이를 기준으로 평가를 하게 됩니다. 평가 결과는 품질평가표에 정리하게 됩니다. 메타데이터 작성의 경우 여러가지 항목을 입력해야 하기 때문에 국토지리원에서는 메타데이터 편집기를 제공하고 있습니다. 

이렇게 작성된 공공측량결과는 국토지리정보원에 사본을 제출하도록 규정되어 있는데, 이때 품질평가표와 메타데이터를 함께 제출해야 합니다. 

이처럼, 일본에서 작업규정준칙(우리나라의 공공측량작업규정에 해당)에 따라 제품사양서로부터 메타데이터에 이르기 까지의 규정만 지키면 자동으로 공간정보 표준을 지키게 됩니다. 아니, 공공측량인 이상 공간정보 표준을 지키지 않을 수 없습니다. 규정에 정해져 있으니까요.

우리나라에서 여러가지 이유로 공간정보표준을 지키지 않거나 혹은 무시되고 있는데, 일본의 사례를 잘 참고했으면 좋겠습니다.

민, 푸른하늘

원문 : https://psgsv2.gsi.go.jp/koukyou/public/seihinsiyou/seihinsiyou_index.html

====

작업 규정 준칙 제 5 조에는 측량 계획 기관이 공공 측량을 실시하고자 할 때, 측량 성과의 종류, 내용, 구조, 품질 등을 나타내는 제품 사양서를 정하도록 규정하고 있습니다. 본 사이트에서는 공공측량 제품 사양서 등에 대한 정보를 제공합니다.

제품사양서 작성

제품 사양서란

• 어떤 측량 성과를 작성하는가
• 작성하는 데이터의 내용과 구조는 어떠한가?
• 품질은 어느 정도인가 

등을 정한 측량 업무의 발주서류 중 하나입니다. 

• 발주자(측량계획기관)는 제품사양서 등을 사용하여 사업을 발주합니다. 
• 수주자는 제품사양서를 기준으로 데이터를 작성합니다. 

 측량계획기관은 공공측량 실시계획서와 함께, 제품사양서를 국토지리원에 제출해 주십시오.

제품사양서 작성방법

제품사양서 작성방법은 다음의 세가지가 있습니다. 1-3. 중 하나의 방법으로 만듭니다] 

1. "작업규정준칙"을 준용한 "공공 측량 작업 규정"에 따라 업무를 수행할 경우, 제품 사양서 샘플 (① 제품사양서, ② 응용 스키마, ③ 품질 요구 및 평가)을 사용할 수 있습니다. [가장 추천하는 방법]
1. "① 제품사양서" 워드 파일을 다운로드받아, 필요한 내용을 작성해주세요.
2. "② 응용스키마" PDF 파일의 내용을 확인해 주세요.
3. "③ 품질요구 및 평가" PDF 파일의 내용을 확인해 주세요.
4. "① 제품사양서"를 사용하여 작성한 제품사양서를 공공측량 실시계획서와 함께 국토 지리원에 제출하십시오.
   
   【주의】 "② 응용스키마", "③ 품질요구 및 평가"의 내용이 업무에 적합하지 않은 경우, 방법 2 또는 방법 3을 사용하여 제품사양서를 작성하십시오.
   
   
2. 제품사양서에서 "응용 스키마", "품질요구 및 평가" 등을 직접 만들 경우, "④ 원본 작성용 제품사양서" 파일을 다운로드받아 수정하여 작성하십시오. 
   
   
3. 제품사양서 편집기를 활용하면, 모든 제품사양서 항목을 직접 만들 수 있습니다. 단, 제품사양서  편집기는 자세한 응용스키마 UML 클래스다이어그램을 작성할 수 없으므로, 주의하시기 바랍니다.
   

제품사양서 등 샘플

기준점측량

• 제품사양서는 PDF 형식으로 작성하는 것이 원칙입니다. 워드로 작성한 파일은 PDF 형식으로 변환하십시오. 
• 예전 공개한 "제품 사양서 (간략 버전)" 파일은 "① 제품 명세서" 파일로 대체되었습니다.
• 예전 공개한 "제품 사양서 (상세 버전)" 파일은 "④ 원본 작성용 제품사양서" 파일로 대체되었습니다.
  
  

수준측량

• 제품사양서는 PDF 형식으로 작성하는 것이 원칙입니다. 워드로 작성한 파일은 PDF 형식으로 변환하십시오. 
• 예전 "제품 사양서 (간략 버전)" 파일은 "① 제품 명세서" 파일로 대체되었습니다.
• 예전 "제품 사양서 (상세 버전)" 파일은 "④ 원본 작성용 제품사양서" 파일로 대체되었습니다.
  
  

수치지형도

• 표준 제품사양서의 인용 자료 
• 기반지도 정보 원형 데이터베이스 지리공간데이터 제품 사양 (안) 【수치 지형도 편] (2014.4.1) [PDF : 3.8MB] [워드 : 3.6 MB]
• 부속 자료 기반지도 정보의 기초인 수치지형도 데이터 정비 작업을 위한 구현 가이드 (안) (2009.10) [PDF : 569kB]
      ... 본 자료에서 "JGD2000"는 "JGD2011"에 바꾸어 사용하세요. 
• 제품사양서는 PDF 형식으로 작성하는 것이 원칙입니다. 워드로 작성한 파일은 PDF 형식으로 변환하십시오.
  
  

촬영(사진기준점 설치, 촬영, 항공삼각측량

• 본 명세서 샘플은 "작업규정 준칙" 제3편 제3장 제1절 ~ 7절 업무 (사진기준점 설치, 촬영, 항공삼각측량)을 고려하며, 성과품은 "수치 사진"과 "외부 표정 요소 성과표"입니다.
• 제품사양서는 PDF 형식으로 작성하는 것이 원칙입니다. 워드로 작성한 파일은 PDF 형식으로 변환하십시오.
  
  

정사사진 작성

• 제품사양서는 PDF 형식으로 작성하는 것이 원칙입니다. 워드로 작성한 파일은 PDF 형식으로 변환하십시오.
  
  

항공 레이저 측량

• 본 제품사양서샘플의 성과품 (수치 표고 모델)은 그리드 데이터 (x, y, z 값을 갖는 점군 데이터) 입니다. DEM 데이터 (벡터로 격자크기 및 자료범위를 지정하여 z 값만 기술한 데이터)가 아니므로 주의하시기 바랍니다.
• 제품사양서는 PDF 형식으로 작성하는 것이 원칙입니다. 워드로 작성한 파일은 PDF 형식으로 변환하십시오.
  
  

응용 측량

삼차원 점군 데이터 제작

• 이 원본 작성용 제품사양서 샘플(안)은 실시하는 측량 업무나, 필요한 제품 사양에 따라 수정하여 사용하십시오. 
• 제품사양서는 PDF 형식으로 작성하는 것이 원칙입니다. 워드로 작성한 파일은 PDF 형식으로 변환하십시오.

=======

참고자료 : 지리 공간 데이터 제품 명세서 작성 가이드 JPGIS 2014 판 [PDF : 2.1MB]

제품사양서 편집기

아래는 국토지리원에서 공개한 제품사양서 편집기 (지리공간 데이터 제품사양서 작성 지원 툴)입니다. 단, 이 편집기에서는 자세한 응용스키마 UML 클래스 다이어그램을 작성할 수 없습니다. 별도로 작성한 UML 클래스 다이어그램 등을 추가 · 편집해야 하므로 주의하시기 바랍니다. 

[제품 명세서의 작성은 제품 사양서 등 샘플을 사용하는 방법을 권장합니다] 

지리공간 데이터 제품 명세서 작성 지원 도구
지리 공간 데이터 제품 명세서 작성 가이드 JPGIS 2014 판 [PDF : 2.1MB]

품질평가

품질 평가는 "작성한 데이터가 제품사양서에서 규정한 품질을 만족하는지" 확인하는 작업입니다. (수주자가 평가합니다.) 

• 발주자 (측량계획기관)은 제품사양서에 품질에 관한 사항을 규정합니다. 
• 수주자는 제품사양서를 기준으로 데이터를 제작하고 측량성과에 대한 품질을 평가합니다. 
• 품질평가표를 보면 데이터 품질(합격 여부)을 알 수 있습니다. 
  

측량 계획 기관은 국토 지리원에 측량 성과를 제출 할 때, 품질 평가표 사본도 제출하십시오. 

품질 평가표는 개별 표에 각 품질 요소의 평가 결과를 기재하고, 총괄표에 합격 여부를 기재합니다. 아래에 있는 품질평가표 샘플을 제품사양서 품질 요구에 따라 변경 한 후 사용하십시오. (수치 지형도 데이터 등, 여러가지 지형지물이 포함된 측량 성과의 경우, 각각의 지형지물별로 별도의 표를 작성하십시오)

기준점 측량

수준 측량

수치지형도

※ 데이터 품질 적용 범위는 임의로 10 가지 예를 넣었습니다. 실제 사양에 따라 재작성하십시오.

촬영

정사사진 제작

항공 레이저 측량

응용측량

3차원 점군 데이터 제작

메타데이터

메타 데이터란 "데이터(측량 성과)에 대한 요약 데이터"로서, 검색 등에 사용됩니다. 

• 발주자(측량계획기관)는 제품사양서에 메타데이터 작성 규정을 기재합니다.
• 수주자는 제품사양서에 따라 메타 데이터를 작성합니다. 
• 메타데이터는 검색 시스템 등에서 이용되어, 측량 효율화에 도움이 됩니다. 
  

측량계획기관은 국토지리원에 측량 성과를 제출할 때, 메타데이터 사본도 제출하십시오. 

메타 데이터 편집기를 사용하면 메타 데이터를 쉽게 작성할 수 있습니다. 자세한 내용은 다음을 참조하십시오. 

• 메타 데이터의 작성에 대해
• 공공 측량 용 메타 데이터 편집기 다운로드 (2013 년 6 월 25 일 ver2.2 공개)

문의처

본 사이트에 관한 질문 등은 다음 문의 양식으로 접수하고 있습니다. 

문의 양식

====

원문 : https://psgsv2.gsi.go.jp/koukyou/public/seihinsiyou/seihinsiyou_index.html

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

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

공간데이터 교환을 위해 가장 좋은 포맷은 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

며칠 전 Enterprise Architect를 사용하여 공간정보 표준 클래스다이어그램을 그리는 방법에 대한 글을 작성했습니다. Enterprise Architect(EA)는 ISO TC211에 참여하는 분들이 사용하는 도구이기 때문에 공간정보 표준과 관련된 일을 하는 분들에겐 무척 편리한 도구라고 말씀드렸습니다. 사용법 자체도 다른 도구와 별반 다르지 않게 직관적으로 사용할 수 있어 좋은 것 같았고요.

제가 그 글을 쓸 때 참고한 글은 Inspire Repository Tutorial 이라는 글로서, INSPIRE 표준에 참여한 분들을 위한 입문서입니다. 그런데, 사실 그 글을 작성하면서 몇가지 어려운 점을 겪었습니다. 먼저 제가 사용한 버전은 13.0 버전인데, 이 입문서에서 사용한 버전은 이전 버전으로서 UI가 너무 많이 바뀌는 바람에 명령을 일일이 찾아야 했다는 겁니다. 그래도 최신판이 낫겠거니 하고 계속 사용하려고 했는데, 다른 글을 참고해보니, 12버전을 사용해서 테스트했고 이후 버전엔 테스트하지 않았다는 내용이 있어.. 결국 다시 12버전을 설치했고, 앞으로도 계속 이 버전을 사용하기로 했습니다.

또 한가지... 더 중요한 사항은 제가 Subversion(SVN) 아이디/비밀번호가 없어서 ISO TC211 표준에 대한 저장소(https://inspire-twg.jrc.it/svn/iso/)를 SVN으로 다운드로 받을 수 없었고, 그래서 그중 implementation-XML 부분만 일일이 수작업으로 복사해서 넣었다고 말씀드렸는데, 이게 완전히 잘못되었다는 것입니다. 아이디/비밀번호가 없어도 다운로드 받는 방법이 있었고, 특히 implementation-XML 부분은 현재 작업중인(체크아웃-체크인하기 위한 임시) 디렉토리여서 이걸 사용하면 안된다는 것이었습니다. 

아무튼... 그래서 ISO TC211의 표준 저장소에서 자신의 PC로 ISO 표준에서 사용중인 모든 클래스다이어그램 등을 불러오는 작업을 수행해 보겠습니다. 

참고로 이 글은 조화 모델 저장소 접근방법이라는 글을 그대로 따라한 것입니다. 여기에서 조화 모델(Harmonized Model)이라는 뜻을 정확히는 잘 모르겠지만요.

ISO 표준 패키지 가져오기

소프트웨어 설치

먼저 두가지 소프트웨어를 설치해야 합니다.

첫번째는 Enterprise Architect. 최신버전보다는 12.1 버전을 사용하세요.

두번째는 SVN 클리언트 프로그램. 여기 들어가면 여러가지가 있는데, 원문에서 Tortoise SVN을 사용해서 저도 여기에서 다운로드 받아 설치했습니다. http://tortoisesvn.net/downloads.html

SVN 으로 파일 받기

그 다음, 자신의 컴퓨터에 작업 공간을 만들어야 합니다. 아무곳이나 만들어도 되지만 한글 디렉토리는 피하는 게 좋습니다. 저는 시키는대로 "C:\Standards/ISOTC211"에 설치를 했습니다. 설치할 위치를 정하면 그곳에 iso라는 이름의 폴더를 추가합니다. 이 폴더가 root 폴더가 되어 저장소에 있는 파일들과 폴더들이 여기로 복사됩니다. 

다음 저장소에 있는 파일을 체크아웃합니다. 아래 그림과 같이 "iso"  폴더를 우클릭하고 "SVN Checkout..."을 선택합니다.

대화상자에서 UML에 아래와 같이 https://inspire-twg.jrc.it/svn/iso/을 입력하고 OK를 누릅니다.

이렇게 실행하면 아래와 같이 경고메시지가 발생합니다. 인증서가 잘못되었다는 뜻이라는데, 원래 이렇게 발생한다고 하더군요. Accept를 누르면 실행됩니다.

이제 Tortoise SVN이 isotc211 모델의 저장소에 대한 복사본을 현재 폴더에 설치합니다. 설치가 완료되면 다음과 같은 대화창이 뜹니다.

폴더 구조는 다음과 같습니다.

Enterprise Architect 환경설정

먼저 EA를 실행하고 기존의 프로젝트를 열거나 새로운 프로젝트를 생성합니다. 

다음으로 아래 화면과 같이 버전 콘트롤 설정을 합니다. 

Project -> Version Control -> Version Control Setting

대화창에는 다음과 같이 입력합니다.

- Unique ID : ISOTC211
- Type : Subversion
- Working Copy Path : 위에서 만든 iso 폴더의 경로 (예: C:\Standards\ISOTC211\iso)
- Subversion Exe : Tortoise SVN이 설치된 위치. (예: C:\Program files\TortoiseSVN\bin\svn.exe)

이제 Save를 누르고 잠시 기다리면 아래 화살표처럼 정의되었다는 내용이 뜹니다. 이제 Close를 누릅니다.

 패키지 가져오기

Project Browser 에서 Model을 우클릭한 후, Package Control -> Get Package를 선택합니다. 그러면 아래와 같은 대화상자가 뜨는데, 아래와 같이 Select a Version... 에서 "ISOTC211"을 선택하면 자동으로 목록을 가져옵니다. 이제 "isotc211\ISO_TC211.xml 을 선택하고 OK를 눌러줍니다.

최신버전 가져오기

잠시 기다리면 Project Browser에 아래와 같이 목록이 나타납니다. 현재는 모두 빈 목록뿐입니다.

여기에서 또다시 Model을 우클릭하고 Package Control -> Get All Latest를 눌러줍니다. 다음 대화창에서는 "Import changed file only" 옵션을 선택합니다. 그러면 모든 패키지가 새로 갱신됩니다. (이 경우엔 모두 새로 채워줍니다. 언제든지 최신 버전이 필요하면 이 명령을 수행하면 됩니다.) 모든 패키지가 들어오기까지는 상당한 시간이 소요됩니다.

이제 완료되었습니다. 모든 패키지가 Locked 되어 있어 편집은 안되지만, 살펴볼 수는 있습니다. 이 상태는 EA <-> Client (나의 PC) <-> Server <-> 저장소(Repository) 간의 연결이 끝난 상태입니다. 즉 필요할 때마다 Get All Latest를 눌러주면 상태를 체크하여 최신 패키지로 모두 갱신됩니다.

저는 ISO 패키지를 사용만 하는 입장이라, 이걸로 충분합니다만, 이들을 편집하고 싶다면 여기를 읽어보세요.

참고로 원래 EA에서 사용하는 파일 포맷은 MS Access 라고 합니다. 당연히 이진파일입니다. 그런데 SVN(을 비롯한 모든 종류의 버전관리 도구)은 이진파일의 버전관리는 불가능합니다. 그래서 EA에서는 자신의 파일을 XMI(UML 교환용 포맷으로 XML 형식)으로 내보내고, 이것을 내 로컬 저장소에 저장을 합니다. 그리고 이 로컬 저장소를 서버와 통신해서 버전관리를 하는 방식입니다. 상당히 영리한 방식이라고 할 수 있습니다. 

그런데, EA에서 사용하는 XMI 파일은 클래스등의 객체 구조 뿐만아니라, 색깔, 다이어그램 상의 위치 등 다양한 정보를 보관한다고 합니다. 따라서 EA가 아닌 UML 도구는 EA의 XMI 파일을 정상적으로 다룰 수 없고, 따라서 다른 UML 도구는 소스 버전관리가 불가능합니다. 이런 점에서도 공간정보 표준과 관련된 작업을 하려면 어쩔 수 없이 Enterprise Architect를 사용할 수 밖에 없을 것 같네요.

No-SVN 환경의 ISO TC211 패키지 가져오기

사실 표준 제정/개정 등의 작업에 참여하지 않는 저같은 사람들은 위와 같이 모든 저장소의 내용을 다운로드 받고, 또 최신판으로 유지할 필요는 없습니다. 그냥 안정된 버전을 다운로드 받아 사용하는 것이 가장 편합니다. 여기에 들어가서 ISOTC211_HM_NoSVN.eap를 받아서 사용하면 됩니다.

아래는 이 파일을 받아서 그냥 EA에서 불러들인 후, GFM(일반 지형지물모델 : General Feature Model) 클래스 다이어그램을 표시한 화면입니다. 좌측위 "Project Browser"를 보시면 ISO TC/211 표준 뿐만 아니라, OGC 표준 그리고 ISO TC211 표준에서 참조하는 기존 표준(예: ISO 3166 국가코드)들도 포함되어 있음을 알수 있습니다. 아주 편리할 것 같습니다. ㅎㅎㅎ

ISO 19000 시리즈 클래스 관계 확인하기

제가 제일 많이 사용하는 기능은 ISO 19000 표준시리즈에 포함된 여러가지 클래스간의 관계를 확인하는 것입니다. 제가 요즘 여기저기 표준관련 문서를 뒤적거릴 일이 많다보니, 어떤 클래스가 어떤 속성이 있고, 다른 클래스와 어떤 관계가 있는지 등을 알아봐야 할 때가 많기 때문입니다.

일단 위와 같은 방법으로 ISOTC211_HM_NoSVN.eap를 불러왔다고 가정하고 시작하겠습니다.

제일먼저 어떤 클래스가 있는지 확인하고 싶을 때에는 Cntl_F (Find in Project) 창을 불러서 아래의 위치에 원하는 클래스명을 입력하면 됩니다. 아래는 DateTime 클래스를 검색한 예인데, 아래와 같이 나타난 여러개의 클래스 중에서 적당한 것을 선택하시면 됩니다. 클래스 중에서 Status가 Supersede라고 되어 있는 경우가 있는데, 이 녀석은 과거 버전이므로 사용해서는 안됩니다. Implemented도... 정확히 무슨 내용인지 아직 모르지만, 어쨌든 Status가 Approved 인 것을 선택하면 됩니다.

선택한 상태로 오른쪽 마우스 클릭을 하면 위와 같이 여러가지 옵션이 나타납니다. 여기에서 Properties... 를 누르면 아래와 같이 이 클래스의 특성을 볼 수 있습니다. 왼쪽 화살표를 누르면 연관관계를 확인할 수 있고요, 오른쪽 아래의 "Details"를 누르고 다시 "Attribute"를 누르면 속성을 확인할 수 있습니다.

또 위의 그림에서 "Find in Diagrams..."를 누르면 아래와 같은 창이 나오고  아무 다이어그램이던 더블클릭하면 이 클래스가 포함된 다이어그램을 확인할 수 있습니다. 원래 이 저장소(ISOTC211_HM_NoSVN.eap)는 ISO TC/211 위원들이 실제 표준 문서 작업을 할 때 사용하던 것과 동일한 복사본이기 때문에, 표준문서에 포함되어 있는 그림들을 포함해 다양한 다이어그램을 확인할 수 있습니다.

그런데 이런 식으로 확인하는 것만으로는 한계가 있을 수 있습니다. 예를 들어 필요에 따라 연관관계에 있는 다른 클래스들을 확인하고 싶지만, 다이어그램에는 숨겨두었을 수 있기 때문입니다. 

이 때에는 다이어그램에서 해당 클래스를 우 클릭한 뒤, 콘텍스트 메뉴에서 "Insert Related Elements"를 선택하면, 아래와 같이 연관관계나 상속관계에 있는 클래스들을 볼 수 있고, 이들을 클릭하면 해당 클래스들이 다이어그램에 추가됩니다. 이때 화살표 쪽을 선택하면 Relation depth를 조절할 수 있습니다.

이상입니다.

민, 푸른하늘

===

원문 : https://github.com/ISO-TC211/HMMG/wiki/Connecting-to-the-Harmonized-Model-Repository

얼마전 Modelio 3.7 을 사용해서 공간정보표준 클래스 다이어그램을 작성하는 방법을 올렸습니다. 이번에는 Enterprise Architect를 사용해서 작성하는 방법을 말씀드리려고 합니다.

Enterprise Architect은 상용 UML Tool입니다. 제일 저렴한 개인용 버전도 $229입니다. 그럼에도 이 도구를 사용하려고 생각한 것은 이 도구가 ISO/TC 211에서 추천하는 (그리고 사용중인?) 도구라는 걸 알게 되었기 때문입니다. 유럽연합의 공간정보기반인 INSPIRE에서도 이 도구를 사용하고 있고요.

게다가 조금 뒤져보니 GML을 지원해주고 있다고 하니, (제가 아직 GML을 잘 모르지만) 아주 유용할 것 같다는 생각이 들었습니다. 우리나라에는 ArcGIS 를 사용하는 기관이 많은데, ArcGIS 모델도 지원한다고 합니다. 

또 한가지 이유는 Modelio 3.7에서는 문서화 도구가 없는데 비하여(제가 못찾은 걸 수도 있습니다.), Enterprise Architect(앞으로는 EA로 쓰겠습니다.)는 문서화 도구가 아주 좋은 듯합니다. 원래 ISO 표준에서는 응용스키마에 대한 문서를 UML 도구에서 지원하는 문서화 도구를 쓸 것을 강력하게 권고하고 있어서, 문서화도구의 편리성은 매우 중요합니다.

어쨌든... 어찌어찌... Enterprise Architect 13 버전을 구해서 테스트해 보기로 했습니다. 이 글은 Modelio와 비교하기 쉽도록 가능한 한 체계를 동일하게 유지하도록 노력했으니 참고하세요.

*******
참고 : 이 글은 Enterprise Architect 13.0 버전을 사용하여 작성했습니다. 하지만, ISO TC 211에서는 12.1 버전을 사용하고 있습니다. 따라서 12.1 버전을 설치하여 테스트하실 것을 적극 추천합니다. 또한 이 글의 "ISO 19100 기본패키지 Import" 부분은 제가 잘못 이해한 내용이 담겨 있으니 이 글을 참고하시기 바랍니다.
*******

1. Project 생성

EA를 처음 사용하려면 먼저 프로젝트를 생성해야 합니다. 아래와 같이 EA 화면 맨 오른쪽 위를 누르고 New Project를 클릭한 뒤, 폴더와 프로젝트명을 입력하면 됩니다.

그 다음엔 "Model Wizard"라는 게 나오는데, (저도 잘 모르니까) 아무것도 선택하지 않고 [확인] 버튼만 눌러줍니다.

다음으로 View를 만들어 줍니다. 아직까지 View의 역할은 잘 모르겠지만... 아래와 같이 Project  Browser 창에서 'Model -> Add -> Add View"를 선택하면 됩니다.

2. 패키지 만들기

패키지는 서로 관련이 깊은 클래스들의 모임입니다. 하나의 프로젝트에는 여러개의 패키지가 들어 있고, 서로 관계가 있을 수 있습니다. 아래는 JPGIS2014의 Geometry/Topology 패키지에 포함된 하위패키지들의 상호관계를 나타낸 것입니다. 이처럼 패키지로 구성된 프로젝트라면 패키지를 만들고 시작하는 것이 좋습니다. (물론 클래스부터 만들고 나중에 패키지로 만들어 정리해도 됩니다.)

참고로, 아래 그림은 EA의 기능을 이용해서 만든 그림입니다. Publish -> Save Image -> Save to File로 저장한 건데, 좀 흐릿해서 배율좀 올리려했더니 잘 안되네요. 

아래는 Start->View-Preference->Diagram->Gradient and Background에서 배경을 완전히 없앤 뒤 화면을 캡쳐한 것입니다. 저는 이게 더 깔끔하니 좋네요.

패키지를 만들 때는 만들어둔 View를 우클릭한 뒤, Add Package... 를 클릭하면 됩니다.  (여기서도 Model Wizard에서는 아무것도 선택하지 않았습니다.

2-1. ISO 19100 기본패키지 Import

제가 Modelio를 사용할 때 답답했던 점 중의 하나는, ISO 19100 표준 시리즈에 원래 포함되어 있던 많은 클래스나 패키지 정의를 새로 만들어야 했던 것입니다. 분명 누군가는 19100 표준에 포함된 정의를 이미 만들어 두었을 텐데, 어디에서 그걸 찾을 수 있을지 막막하여 결국 제가 필요한대로 새로 만들어 사용했었습니다.

그런데, EA로 작업하다보니 그럴 필요가 없었습니다. 이미 만들어진 19100 시리즈의 클래스 다이어그램 등을 모두 구할 수 있었기 때문입니다. 

여기에 들어가 보시면 아래의 화면과 같이 나타납니다. 원래 이곳은 유럽연합의 공간정보기반인 INSPIRE에서 관리하는 사이트로서, 원래는 SVN (subversion)이라는 소스관리 도구로 관리되고 있는 ISO 19100 시리즈 표준의 기본 패키지입니다. 

기본 패키지라고 써둔 이유는, 응용스키마를 작성할 때 참조해야 하는 패키지가 모두 포함되어 있기 때문입니다. 다른 표준들에서도 이 표준을 참조하고 있으며, 사용자들이 공간정보 응용스키마를 작성할 때에도 여기에 포함된 ISO TC-211 패키지만 참조해서 사용하면 됩니다.

참고로, 이 상위 폴더를 찾아보면, 다른 표준에 들어 있는 클래스 다이어그램들도 모두 볼 수 있습니다. 계속해서 작업이 이루어지고 있어 예전 버전과 최신 버전을 모두 찾아볼 수 있습니다. (이 저장소는 ISO 표준 관계자들의 공식 저장소 중 하나라고 어디에선가 읽었습니다.)

원래는 SVN으로 관리되므로, 이들 내용을 받을 때도 SVN을 사용해야 하지만, 저는 id/pw를 받지 못해서 그냥 이곳에서 모두 일일히 다운로드 받았습니다. 아래는 그중 일부입니다. 이중 파일 크기가 큰 것 두개부터 import한 뒤, 파일 크기가 작은 것을 import하면 구조가 자동으로 정리가 됩니다. 패키지 또는 뷰에서 우클릭하고 import/export->import package from XMI files... 명령을 사용하면 읽어들일 수 있습니다. 

아래가 제가 모두 읽어들인 결과입니다.

아래는 이렇게 정리한 파일을 모두 한꺼번에 Export 한 것입니다. ISO 공간정보 표준과 관련하여 클래스다이어그램이 필요하시면, 이 파일만 읽어들여서 사용하시면 됩니다.

19100All.zip

3. 클래스 다이어그램 만들기

이제 본격적으로 클래스 다이어그램을 만들어볼 차례입니다. 아래 그림과 같이 원하는 패키지에서 우클릭한 뒤, Add diagram을 선택하면 됩니다. 만들어진 다이어그램은 나중에 편한대로 다른 위치로 옮길 수 있지만, 설명하고자 하는 패키지 내부에 만드는 게 가장 좋습니다.

그 다음 나오는 대회상자에서 UML Structural -> Class 를 선택하고 적당한 이름을 준 뒤 확인버튼을 누르면 해당 패키지 속에 클래스 다이어그램이 추가됩니다. 참고로 아래 대화상자에서 보시는 것처럼, 아주 다양한 종류의 다이어그램을 생성할 수 있습니다. ArcGIS도 보이고... 아래쪽으로 더 내려가면 GML도 보이더군요. (그런데 아직까진 GML 다이어그램이 뭘까... 싶네요)

4. 클래스 생성하기

다이어그램 상태에서 클래스를 만들 때에는 아래 그림과 같이 Toolbox에서 Class->Class를 선택한 뒤, 다이어그램내 적당한 위치에서 클릭해주면 됩니다.(드래그&드롭은 안됩니다.) 이때 클래스 명은 "Class1, Class2" 등으로 만들어지는데, 여길 선택해서 적절한 이름을 넣어주면 됩니다.

이렇게 그래픽으로 추가하지 않고(그림은 만들지 않고), 정의만 생성할 수도 있습니다. 적당한 대상(Package 등)에서 Add element를 선택하면, 아래와 같은 대화상자가 나타나는데, 여기에서 클래스를 직접 추가할 수 있습니다. 

이렇게 클래스 정의만 있는 상태에서 클래스다이어그램에 추가하려면 그냥 Drag&Drop을 하시면 됩니다. 그러면 아래와 같은 대화상자가 나타나는데, Link를 선택하면 됩니다.

참고로 클래스 다이어그램에서 클래스나 link를 선택한 상태에서 Del 키를 누르면, Diagram에서 삭제가 되지만 정의 자체는 패키지에 삭제되지 않은 채 남아 있습니다.

5. 속성(Attribute) 추가하기

EA에서 속성을 추가하려면, 아래 그림과 같이 Project Brower에서 원하는 클래스에 우클릭하고 Attribute... 를 클릭하면 됩니다.

그러면 아래와 같은 대화상자가 나타납니다. 여기에서 속성의 name, 유형, 초기값, 다중도(Multiplicity) 등 원하는 값들을 선택하면됩니다. 그런데, 공간정보 응용스키마를 생성하려면 속성의 유형은 UML의 기본 속성유형(int, boolean, byte 등)이 아니라, ISO 19103 개념스키마의 기본 유형(Integer, Boolean, CharacterString 등) 이나, 다른 표준 패키지에서 정의된 유형을 지정해야 합니다.

이를 위해서는 아래 그림과 같이 유형에서 맨 아래에 있는 "Select Type..."을 선택하고

아래와 같은 대화상자에서 해당 유형을 직접 선택하거나, 빨간 화살표를 쳐둔 "Search"를 눌러 검색해서 입력하면 됩니다.

아래는 이렇게 속성을 추가한 뒤의 클래스의 모습입니다. 아주 깔끔하게 (Modelio 와는 달리 초기값도) 잘 나오네요.

6. 연관관계 생성하기

연관관계는 주로 다이어그램에서 생성합니다. 아래 그림과 같이 좌측 Toolbox에서 원하는 관계를 선택한 후, Source 클래스를 먼저 클릭하고 Target 클래스를 선택해 주면 됩니다. Source 클래스를 클릭하면 우측 빨간화살표와 같이 화살표가 나타나는데, 이것을 클릭하고 Target 클래스를 지정해줘도 됩니다.

연관관계에는 적절한 role을 부여해야 합니다. 연관관계 선을 더블클릭하면 다음과 같은 대화상자가 나오는데, 여기에서 Role(s)를 선택하고 적절한 role 이름, 다중도, 탐색가능(Navigability) 등을 지정해줍니다.

그러면 아래와 같이 associationrole 이 예쁘게 나타납니다.

7. 스테레오타입 추가하기

공간정보표준중 KS X ISO 19103 개념 스키마 언어 6.10.2에는 여러가지 스테레오타입이 나옵니다. 패키지에 대한 스테레오타입으로는 <ApplicationSchema><leaf>이 정의되어 있고, 클래스에 대한 스테레오타입으로는 <CodeList> <DataType> <FeatureType> <Union> <Type>등의 스테레오타입이 정의되어 있습니다. 물론 이 외에도 새로운 것을 정의하여 사용할 수 있다고 규정되어 있습니다.

스테레오타입은 여러가지로 사용될 수 있는데, 공간정보표준에서 사용되고 있는 스테레오타입은 의미의 확장, 혹은 의미의 명확화라고 생각할 수 있습니다. 즉, 모두다 클래스이지만, <FeatureType>라는 스테레오타입을 사용한다면, 이 클래스는 지형지물임을 명확히 알 수 있게 됩니다.

Modelio의 경우, 모든 스테레오타입을 새로 정의해서 사용해야 했지만, EA에서는 기존 정의되어 있는 것을 그대로 사용할 수 있습니다. EA에 GML 을 지원해주고 있다고 했는데, 여기에서 조금 도움이 되네요.

클래스에 대하여 스테레오타입을 지정하는 예를 살펴보겠습니다. 먼저 다이어그램이나 Project Browser에서 원하는 클래스를 더블클릭하면 아래와 같은 대화상자가 나타납니다. 여기에서 맨오른 쪽위에 있는 Strerotype을 클릭하고 새로나오는 대화상자에서 Profile을 열고 GML을 선택합니다.

그러면 아래와 같이 GML에서 사용할 수 있는 스테레오타입이 모두 나타납니다. 여기에 있는 스테레오타입은 ISO TC-211 표준의 스테레오타입과 일치하니까 이걸 사용하면 됩니다. 

참고로 패키지에 대해 스테레오 타입을 지정하면 아래와 같이 나타납니다.

아래는 이상과 같은 과정을 통해 작성한 테스트용 클래스 다이어그램입니다. 깔끔하니 잘 만들어지네요.

8. 문서화(Documentation)

일단 여기까지 순조롭게 진행되니, 문서화 기능도 테스트해보고 싶어졌습니다. Publish->Document->Generate Documentation을 누르면 아래와 같은 화면이 뜹니다. 여기에서 파일명과 출력포맷(.rft와 .pdf 등)을 지정하고, 오른쪽에 있는 Generate를 누르면 문서가 생성됩니다.

아래가 이렇게 만들어진 문서입니다. 오른쪽 위에 날짜가 약간 깨진 것 빼놓고는 괜찮네요. rtf 포맷을 만들면 Word 같은 도구로 편집할 수 있고, 템플릿을 지정하는 기능도 있으니, 적당하게 편집하면 예쁜 문서를 만들 수 있을 것 같네요.

===

이상입니다. EA를 처음 써보는 중이라 아직도 모르는 것 투성이지만, 아주 편하게 잘 사용할 수 있을 것 같네요. 

민, 푸른하늘

이 글은 KS X ISO 19109 응용스키마 규칙을 정리한 글입니다. 이 표준에 따라 응용스키마를 제작하려면 무엇을 해야 하는지, 뭘 유의해야 하는지 등에 대하여 썼지만, 완전한 해설서라기 보다는 제가 아는 만큼만 정리하고, 제 생각에 따라 적은 글이라는 것을 밝힙니다. 개인적인 주장도 담겨 있으니, 참고만 하시길 바랍니다. 

혹시 다른 의견이 있으시다면 이글에 댓글이나 이메일이나 페이스북을 통해 알려주시면 감사하겠습니다.

원문 : ISO Standard 19109:2015 Geographic information — Rules for application schema
        KS X ISO 19109 지리정보 - 응용스키마 규칙

응용스키마 예제

일단 먼저 원문(부속서 C.1)에 포함되어 있는 응용스키마를 살펴보겠습니다. 거꾸로 시작하는 것도 재미있거든요.

이 그림은 가상의 고압송전망입니다. 여기에서 A와 B는 중앙변전소, C는 송전타워입니다. 실선은 고압송전선, 점선은 중앙변전소 경계를 나타냅니다.

응용스키마

이들에 대한 응용스키마는 응용의 목적/제작자/주변환경 등에 따라 달라집니다. 사실은 백인 백색이라고 할 수 있습니다. 비슷해 보여도 디테일은 모두 다를 수 있으니까요. 어쨌든... 이 표준에서는 아래와 같이 응용스키마를 구성했습니다.

먼저, 변전소는 두가지(중앙변전소, 송전타워)가 성격이 비슷하므로, 먼저 Substation을 정의하고, MainSubstation과 TowerSubstation이 이를 상속받도록 정의했습니다. 

MainSubstation(중앙변전소)의 속성은 (상속받은 속성을 포함해서) 이름, 주소, 공간 속성 두 가지 등 총 4가지 속성이 있습니다. 공간속성중 하나는 topology의 일부가 되는 topologyRelatedBy(TP_Node 유형), 그리고 중앙변전소의 경계를 나타내는 geometricallyDescribedBy(GM_Surface 유형) 입니다.

TowerSubstration(송전타워)도 4개의 속성이 있는데, 공간속성은 GM_Point 유형 과 TP_Node 유형의 두가지입니다.

TransmissionLine(송전선)은 공간 속성(geometricallyDescribedBy)이 GM_Curve 유형이고, 위상속성은 TP_Edge 유형입니다. 

마지막으로 UtilityNetwork은 전력망 전체를 나타내는 위상체계입니다. 속성은 topology 하나가 있습니다. topology는 데이터유형이 TP_Complex입니다. 위상복합체라고 하는데, 이 데이터를 뒤져보면 이 송전망의 모든 위상구조가 담겨있습니다. 그 속엔 변전소(TP_Node)와 송전선(TP_Edge)가 서로 연결되어 있을 것입니다.

이러한 그림을 UML 클래스다이어그램이라고 합니다. 응용스키마는 UML 클래스 다이어그램으로 생성해야 합니다. 

참고로... 저라면 다르게 구성할 겁니다. 제 생각은 이 글 맨 아래를 확인하시면 됩니다.

패키지 다이어그램

이와 같이 응용스키마를 만들 때, 패키지 다이어그램도 함께 작성해야 합니다. 아래가 이 응용스키마의 패키지 다이어그램입니다. 작성한 응용스키마(스테레오타입 «ApplicationSchema»라고 붙어있음)가  ISO 19107 공간 스키마 패키지를 사용하고 있다는 뜻입니다. 그리고 중간에 메모로 표시한 것은 공간스키마 중에서 사용하는 유형이 어떤 것인지를 나타내는 것입니다. (이것은 반드시 적어야 할 필요는 없습니다.)

이러한 의존관계는 UML 도구를 사용하여 작성하고, ISO 표준에 포함되어 있는 표준 스키마 패키지들을 적절히 가져올 경우 자동적으로 생성됩니다.

지형지물의 문서화

응용스키마는 클래스다이어그램 뿐만 아니라, 이 다이어그램에 표현된 지형지물 및 속성에 대한 자세한 내용이 필요합니다. 그림에는 안보이지만 UML을 작성할 때 기록해 둔 자세한 내용 및 추가적인 정보를 문서화해야 하기 때문입니다.

다음은 송전선에 대한 상세한 내용입니다. 지형지물 유형 그 자체와, 세가지 속성에 대해 자세한 내용을 볼 수 있습니다. 물론, 다른 지형지물에 대해서도 이러한 문서를 작성해야 합니다. 

이와 같은 UML 클래스다이어그램은 원래 UML 툴을 사용하여 작성하게 되어 있습니다. 시스템을 개발하는 분들은 UML 툴을 많이 활용하고 잘 알겠지만, UML 툴에는 클래스 다이어그램에 대한 상세한 내용을 문서로 뽑아내는 기능이 있습니다. 19109에서는 이러한 기능을 이용해 문서화해야 한다고 규정하고 있습니다. 

물론 UML을 일반 그림도구나 PowerPoint 등으로 그릴 수도 있습니다. 그 경우엔 문서화를 따로 할 수 없어 수작업으로 만들어야죠. 하지만, 이렇게 되면 UML과 지형지물 요소의 문서가 일치하지 않을 가능성이 높습니다. 따라서 반드시 UML 도구를 사용해야 한다고 생각하면 맞습니다.

제가 얼마전 올린 Modellio 3.7 도 이런 도구중 하나입니다. 그리고 ISO TC/211에서는 "Enterpise Architect"라는 도구를 추천한다고 하더군요. 하여튼 어떤 것도 좋지만, 응용스키마는 반드시 UML 도구를 사용해서 작성해야 합니다. 

저는 이번 글은 UML 도구를 사용하지 않고 그림을 복사해서 붙여뒀습니다만, 다음에는 도구를 사용해서 문서화하는 기능을 테스트해볼 계획입니다.

응용스키마 작성목적

이 표준의 6.1에는 응용스키마의 목적을 두가지로 밝히고 있습니다.

- 컴퓨터가 읽을 수 있는 표현으로 데이터 구조를 정의함으로써, 자동으로 데이터를 관리할 수 있게함.
- 특정 응용의 데이터 내용을 문서화함으로써, 관계자들이 모두 데이터를 정확하게 이해할 수 있음.

그런데, 제 생각으로는 위에서 작성한 응용스키마 및 문서 만으로는 첫번째 목적을 달성하기는 힘들 것 같습니다. UML 도구를 사용하여 응용스키마를 작성할 경우, 산출물은 클래스다이어그램//데이터 문서(데이터 사전 등)으로 사람들이 데이터를 이해하는 데는 반드시 필요합니다. 하지만, 자동으로 데이터를 관리하기 위해서는 이 응용스키마와 데이터를 직접 비교하고 검증해야 하는데, 이러한 몇가지 문서만으로는 불가능하다고 보이기 때문입니다. (참고로 제가 공간정보 표준과 유통에 대하여 쓴 것처럼, 응용스키마를 XSD로 인코딩하고, 데이터를 XML로 인코딩하면 이러한 검증은 가능합니다)

6.2에는 응용스키마는 제공자와 사용자간의 데이터 전송 및 교환에 매우 중요함을 밝히고 있습니다. 

즉, 이 표준을 사용하면 데이터 교환을 위한 (공통) 전송 응용 스키마 구축할 수 있는데, 구축된 응용스키마를 사용하면 전송된 데이터세트의 의미를 해석할 수 있고, 데이터간 어떠한 변환이 필요한지를 결정할 수 있다고 말하고 있습니다. 한편, 이 표준에 있는 규직을 사용하여, 시스템 내부용 응용 스키마 구축을 위해서도 적용할 수 있기는 하지만, 이러한 응용 스키마는 이 표준의 범위에 속하지 않는다고 밝히고 있습니다.

결국, 응용스키마를 제작하는 가장 중요한 목적은 데이터의 교환이고, 데이터 교환시 데이터의 내용 및 구조를 정확하게 정의하고, 서로 이해하기 위한 목적이라고 요약할 수 있습니다.

응용스키마 작성시 주의사항

응용스키마는 위의 예제와 같이 만들면 됩니다. 복잡하면 크기가 커질 뿐, 이와 같은 형식만으로만 만들 수 있다면 크게 문제는 없습니다. 하지만, 응용스키마를 이렇게 만들기 위해서는 몇가지 지켜야 할 것들이 있습니다.

사실 이 KS X ISO 19109 응용스키마 규칙은, 이와 같은 응용스키마를 작성하기 위한 규칙을 세세하게 정한 것입니다.

공간정보 UML 프로파일

위에 있는 클래스 다이어그램에는 다섯가지 지형지물 클래스가 있습니다. 이 다섯가지 클래스는 모두 스테레오타입이 «FeatureType»으로 되어 있습니다. 이 클래스들이 지형지물(피처) 유형이라는 뜻입니다. 스테레오타입은 19103 개념스키마에 정의되어 있습니다. 그리고 CharacterString, Integer와 같은 기본유형도 개념스키마에 정의되어 있구요. 

사실 공간정보표준은 개념스키마언어로서 UML을 권장(필수가 아니래요!!!)하고 있는데, UML을 그대로 사용해서는 안됩니다. 미리 스테레오타입과 기본유형을 정의해 둔 외에도 여러가지 제한들을 모두 지켜야 합니다. 이것을 (공간정보 표준용) UML 프로파일이라고 합니다. 즉, 공간정보 표준에 따라 응용스키마를 구성할 때에는 UML 프로파일을 사용해야 하는 것입니다.

공간정보표준에서 사용하는 UML 프로파일의 대략적인 내용은 다음과 같습니다. (자세한 내용은 19109 에 포함되어 있습니다.)

- 텍스트, 이름, 숫자, 날짜시간 등에 대한 원시유형(primitive type)/공통구현 유형/파생유형은
  ISO19103에 정의된 것만 사용한다.

- UML 연관의 경우, 반드시 다중도를 명시할것/탐색가능한 연관 끝에는 명시적인 이름이 있을 것

- 역할 이름이 주어진 연관은 클래스의 속성으로 처리할 것

- (권장) 속성, 연산, 연관 역할 이름이 패키지 내에서 유일할 것

- 사용할 수 있는 스테레오타입: Application Schema, CodeList, dataType, enumeration, FeatureType, Leaf, Union, use 등.

- 스테레오타입 이름은 UpperCamelCase로, 표준 UML 키워드는 lowerCamelCase를 사용할 것

이렇게 (공간정보용) UML 프로파일을 정의해 둔 이유는, 응용스키마를 누가 작성하던 동일한 결과가 나오도록 하기 위함입니다. 그냥 UML로 작성한다는 규정만 있다면, 동일한 내용을 작성한다고 해도 사용자마다 차이가 생길 수 있기 때문에, 이를 방지하는 목적이죠.

GFM(일반 지형지물 모델)

공간정보 응용스키마에서 가장 중요한 것은 지형지물(Feature)입니다. 지형지물은 공간상의 위치가 있는 것 뿐 아니라, 없는 것들도 모델링 할 수 있고, 해야 합니다. 지형지물은 기본적으로 UML 클래스입니다. 그냥 일반 클래스가 아니라, 형식이 엄격히 정해져 있는 클래스죠. 이러한 지형지물을 정의하기 위한 개념을 일반지형지물 모델이라고 합니다. (이를 응용 스키마의 메타모델(MetaModel)이라고 합니다.)

아래가 ISO I9109:2015에 정의되어 있는 일반 지형지물 모델입니다.

여기에서 FeatureType이라는 메타클래스에 대해서 좀 더 살펴보겠습니다. 일단 FeatureType은 IdentifiedType에서 상속을 받았고, 그래서 FeatureType의 속성에는 isAbstract(추상 지형지물인가 아닌가) 외에도, name(지형지물 유형 이름), definition(정의), description(설명), designation(지정... ), 그리고 constraintedBy 등이 들어있습니다. 여기에서 name과 definition은 필수입니다. 

아래쪽 다이아몬드는 Feature가 여러 Property(Attribute, Operation, FeatureAssociationRole)를 가질 수 있다는 의미입니다. PropertyType쪽에 carrierOfCharacteristecs라고 연관역할이 있는데, 이는 이 Property들의 집합에 대한 링크입니다.

오른쪽에 있는 자기 자신을 향한 화살표는 상속(일반화/특수화) 관계를 가질 수 있다는 의미고요.

일반 지형지물 모델(GFM)은 일반적인 사용자, 즉 응용스키마를 작성하는 사람은 구지 잘 몰라도 관계는 없습니다. 머... 대부분 비슷한 응용스키마를 참고해서 수정해서 쓰는 저같은 사람은 특히나 필요없죠. 하지만, 여기에 있는 내용은 반드시 지켜야 합니다. 예를 들어, 지형지물에 대한 설명을 할 때에는 반드시 description이라는 속성을 사용해야 하고, desc 같은 걸로 임의로 바꾸면 안된다는 뜻입니다.

지형지물 정의

지형지물(Feature)를 정의할 때 지켜야할 사항은 /req/general/feature (7.4.5 FeatureType)에 정의되어 있습니다.

첫번째, 지형지물은 메타클래스 FeatureType의 인스턴스로 모델링되어야 한다.
두번째, 지형지물은 GM_Object 또는 TM_Object의 하위 유형으로  모델링되어서는 안 된다.
세번째, 지형지물 이름은 응용 스키마 내에서 유일해야 한다.

첫번째와 세번째는 위에서도 언급했으니 생략하고, 두번째에 대해서만 생각해보겠습니다. 대부분 GIS를 처음 배울 때 "도형데이터는 점, 선, 면이 있다"로 부터 시작합니다. 그러다보니, 도형=지형지물로 생각하는 경향이 있는데, 이렇게 사용하면 안된다는 뜻입니다. 예를 들어, 공간스키마(19107)에서 기하원시객체(geometric primitive)는 GM_Point, GM_Curve, GM_Surface 등이 있는데, 이것을 직접 지형지물로 사용하지 말고, «FeatureType»으로 정의한 지형지물의 속성으로 사용하라는 것입니다.

그냥 일반적인 UML 문법으로 봤을 때는 «FeatureType»을 사용하여 정의하든, GM_Point 등을 사용하여 정의하던 아무런 문제가 발생하지 않습니다. 하지만, (공간정보 표준) 응용스키마는 모든 지형지물을 스테레오타입이 «FeatureType»인 클래스로만 정의하라는 것입니다.

지형지물에 대한 UML 생성시 지켜야 할 사항은 /req/uml/feature (8.2.6)에 정의되어 있습니다. FeatureType은 CLASS로서 구현하되 스테레오타입을 «FeatureType»로 해야 한다는 것, CLASS이름은 ApplicationSchema 내에서 유일해야 한다는 것. 그리고 해당 CLASS에 대한 텍스트 정의는 UML 도구의 문서화 도구를 이용하여 기록할 것 등의 내용입니다. UML 프로파일에서 대략적으로 이야기했던 내용을 구체적으로 지정한 것입니다.

기타 정의

이 표준에는 이 외에도 응용스키마를 작성할 때 지켜야 할 규칙이 많습니다. 적합성 클래스 기준으로 12가지가 있고, 강제규정과 권고사항을 합치면 약 70가지 정도됩니다. 

여기를 보시면 제가 이 규칙들을 정리해 놓은 구글 스프레드시트를 보실 수 있습니다. 완벽한 건 아니고, 제가 참고삼아 보려고 만든 것이라, 빠진 내용들도 많습니다. 잘못된 점이 있거나 의견이 있으시면 댓글을 달아주세요. (스프레드시트에 댓글을 달린다고 하는데, 한번도 테스트를 안해봐서 모르지만, 어쨌든요~

응용스키마 규칙에 대한 생각

제가 공간정보표준을 보면서 정말 까다롭다고 생각한 부분이 있습니다. 공간스키마와 시간스키마, 그중에서도 위상에 관한 부분입니다. 제가 생각하기에 "유용한" 위상구조는 2차원 도형에 대한 구조인데, 1차원 3차원까지도 위상구조를 정의한다는 건 너무 복잡하기만 할 뿐이라고 생각했었습니다. 위상구조는 대부분의 경우, 공간 원시 객체(geometric primitive)에 일정한 알고리듬을 적용하면 자동으로 만들어 낼 수 있는데, 이걸 데이터 구조에 억지로 끼워넣는다는 느낌도 들었고요.

그런데 이번에 표준에 대해서 살펴보면서 이런 생각을 좀더 굳히게 되었습니다. 응용스키마가 내부 시스템 구조용이 아니라, 주로 다른 시스템간의 데이터 전송을 위한 목적이라는 것입니다. 원래 위상구조를 만드는 목적은 실시간으로 연결성을 계산하려면 많은 계산이 필요하므로 미리 처리해서 데이터 구조로 만들어 둔 것입니다. 따라서, 운영 시스템에서는 위상 데이터가 매우 중요합니다.

하지만 데이터 전송을 위한 공통 응용스키마 제작이 목적이라면,  되도록이면 간단한 구조로 데이터를 전송하는 게 좋다고 봅니다. 수신측에서는 이 데이터를 각자의 시스템 목적에 따라 재가공해야 하므로,  위상구조와 같은 "알고리듬"에 의존하는 항목들은 그때 복원하는 것이 맞다고 결론을 내렸습니다.

커버리지도 이와 비슷합니다. 커버리지는 어떤 특정위치에 대한 특성값을 반환하는 함수로서 기능합니다. 커버리지는 여러가지 지형지물를 기반으로 구성되므로, 커버리지 구조가 없더라도 데이터를 전송하는데는 크게 문제가 없다고 판단됩니다.

클래스의 정의에서 연산(Operation)은 데이터 교환용 응용스키마에서는 사용하지 않는 건 당연하고요.

이런 관점에서 제가 판단했을 때 구지 데이터 교환용 공통 응용스키마에는 별로 필요없겠다고 생각한 것들이 위의 그림에서 노란색으로 표시한 것들입니다.

제가 데이터 교환에 관련된 표준만 관심을 두고 공부하는 중이지만, 아직도 모두 이해하고 있는 건 아니기 때문에 나중에 바뀔 수도 있지만, 당분간은 응용스키마에 관한 한 "되도록 가장 간단한 구조"로 작성할 생각입니다.

따라서!!!

제일 위의 예제도 아래와 같이 바꾸는 게 맞다고 생각합니다. 그림을 보시면 모두 이해할 수 있으리라 생각하고 설명은 생략합니다.

참고 : 데이터 교환은 전송에 의한 방법과 트랜젝션(transaction)에 의한 방법이 있습니다. 트랜젝션의 경우, 사용자가 데이터를 요청하면 이를 처리하여 되돌려주는 방식입니다. 이 방식에서도 응용스키마가 사용되는데, 이 경우, 연산(Operation) 정의를 비롯해 실시간 데이터 처리가 관계되므로 위상구조도 데이터로 보내는 것이 맞다고 봅니다. 

===

이상입니다.

민, 푸른하늘

장면 1

우리나라 정부가 생산 관리하는 데이터를 공개하는 곳인 공공데이터 포털

- 동일한 제목의 자료를, 올린 지자체도 있고, 안올린 곳도 있다.
- CSV, Excel, XML 등 포맷이 제각기.
- 동일한 자료에 대해서도 데이터 제작 주체에 따라 구조가 달라지기도 한다.
    - 예를 들어 열의 갯수가 모두 다른 경우
    - 열로 분리, 콤마로 분리, 분리 안한 것 등등

*참고 : 영국의 경우 www(월드와이드웹)의 창시자 팀버너스리 경(Sir Tim berners-Lee)이 주도하는 ODI(Open Data Institute)와 공동으로, XML 기반으로 데이터 공유 

장면 2

국가 공간정보를 공개하는 국가공간정보포털. (사례 : 버스노선)

- 지도데이터는 존재하지 않고, "공간정보목록정보"에만 존재
    - 목록에 존재하는 지자체는 21개. (군산시는 버스노선마다 따로따로 올려서 51개)
    - 데이터의 내용 및 구조에 관한 정보가 없는 경우 많음(예: 버스노선)
    - 고유주소 없음(예 : 동두천시를 검색한 주소를 복사한후 새창에 붙이면 동작하지 않음
- "국가공간정보포털개방목록"에 BRM 분류가 있으나, 막상 클릭하면 아무것도 없는 항목 다수
- 지방자치단체에서 작성한 데이터는 거의 없는 듯

장면 3

지방자치단체간 데이터 교환

- A 지자체에서 인접한 B 지자체에 도로데이터 요청한다.
- B 지자체는 A 지자체에서 요청하는 포맷으로 변환하여 전송한다.
- A 지자체는 B 지자체의 데이터를 받은 후 그냥 사용할 수 없다. 왜그럴까?

도입

우리나라에서 데이터 교환 또는 유통체계에서 벌어지는 사례를 몇 가지 들었습니다. 공공데이터 포털에서 제공되는 데이터는, 공간정보보다 훨씬 간단한 text 정보임에도 제대로 공개/유통되지 못하고 있다고 많은 사람들이 지적하고 있습니다. 이걸 생각해보면 이보다 훨씬 구조가 복잡한 공간정보에 대한 유통 체계가 문제가 있는 것은 어쩌면 당연할 수도 있습니다.

정보공개/데이터 유통과 관련된 모든 문제는 데이터 유통체계가 미비하기 때문에 발생하는 것입니다. 유통체계가 뭐가 잘못된 것인지를 말하는 대신, 데이터 유통체계가 완벽하게 이루어지면 어떻게 데이터공개/교환/유통이 이루어질 수 있는지를 생각해 보겠습니다.

1. 개인정보보호, 보안 등 현행법에 저촉되지 않는 모든 데이터가 공개된다.
2. 모든 공개된 데이터의 상세한 내용및 구조가 별도의 데이터로서 공개된다.
3. 동일한 이름의 데이터에는 내용과 구조가 완전히 동일하다.
4. Machine Readable 한 포맷으로 공개된다.
5. 공개된 데이터의 구조도 함께 공개되며, 이 구조를 사용하여 자동 검증이 가능하다.
6. 이미 공개된 데이터가 일부 수정된 경우, 수정된 부분에 대해서 즉시 공개된다.
7. 공개된 데이터는 관련자에게 즉시 통지(notification)된다.
8. 해당 데이터의 사용자/기관은 (사람이 개입하지 않고) 자동으로 갱신된 데이터를 읽어오고,
   이 데이터를 사용하여 자신의 데이터를 자동으로 수정한다.

대략 이렇게 정리할 수 있을 것 같습니다. 즉, 데이터를 어느 사이트에 올려 놓는다고 하여 유통이 되는 것이 아니라, 이런 식으로 기계간 통신(Machine to Machine)으로, 사람이 개입하지 않고 자동으로 처리될 수 있어야만 "궁극적"으로 데이터 유통이 된다고 할 수 있습니다. 이렇게만 되면, 어느 생산자든 데이터를 수정하면 그 데이터를 사용하는 사람의 데이터도 자동 수정되어, 결국 "실시간 갱신" 시스템이 완성될 수 있을 것입니다.

이러한 체계를 갖추기는 물론 매우 어렵습니다. 하지만, 불가능한 것은 아닙니다. 데이터 공급자의 의지와 노력 (+ 제도적 뒷받침), 그리고 공간정보 표준을 준수하면 이러한 체계를 갖출 수 있습니다. 그중에서 오늘 제가 할 이야기는 공간정보 표준, 그중에서도 유통과 밀접한 관련이 있는 "데이터의 내용과 구조"에 대한 내용입니다.

데이터의 내용과 구조(응용스키마)

"데이터의 내용 및 구조"를 이야기하면 보통 데이터 교환 포맷을 떠올립니다. 텍스트 위주의 DB라면 CSV나 XML 등이 교환포맷으로 많이 사용됩니다. Excel 파일로 올리는 곳도 많지만요. 공간정보 DB는 Shape 파일이나 GML 등의 포맷이 많이 이용됩니다. 물론 아직 DXF를 선호하는 분들도 있고요. 사실 데이터 포맷 자체는 큰 문제가 아닙니다. 한글파일이나 스캐닝한 영상을 올리지만 않고, 적절한 구조를 지원만 한다면 어떤 포맷을 사용해도 데이터 교환에는 그다지 큰 문제는 없습니다. 즉, (정확한 내용 및 구조를 가지고 있다면) 데이터 교환에 어떤 포맷을 사용해도 문제는 없다는 뜻입니다. 널리 알려지지 않은 포맷이라면 불편함이 더 많아질 뿐입니다.

하지만, 현재 국가공간정보포털에 올려진 파일은, 공각정보분야에서 일하는 사람이라면 누구나 잘 알고 있는 Shape 포맷으로 올려져 있는데, 왜 바로 가져다 쓸 수 없을까요? 그것이 바로 "데이터의 내용 및 구조"에 관한 문제입니다. 

이종 시스템 간의 상호 작용을 성취하기 위해서는 두 가지 근본 문제가 결정되어야 한다. 첫 번째 문제는 공간 데이터의 내용의 의미와 논리적 구조를 정의하는 것이다. 이것은 응용 스키마에서 이루어져야 한다. 두 번째 문제는 응용 스키마와 관련된 데이터를 표현할 수 있으며, 시스템과 플랫폼 독립적인 데이터 구조를 정의하는 것이다."

이 글은 "KSXISO 19118 지리정보 - 인코딩" 표준의 6절에 있는 내용입니다. 이종 시스템간의 데이터 교환을 위해서는 첫번째 "공간데이터의 내용 및 구조" 정의, 두번째 "데이터 포맷" 정의가 필요하다는 뜻입니다.

데이터 포맷은 위에서 언급한 것처럼, 사실 데이터 교환에 참여하는 자들끼리 동일한 포맷을 사용한다면 큰 문제가 아니라고 말씀드렸습니다. 하지만, "데이터의 내용 및 구조"는 완전히 다른 문제입니다. 예를 들어 두개의 기관에서 도로데이터를 각각 다음과 같이 정의하였다고 해보겠습니다. 

A 지자체(좌측)은 모든 도로를 하나의 "Road" 클래스로 분류하고, 5가지 속성을 갖는 것으로 정의했습니다.(이중 두개의 속성은 도형정보입니다.) B 지자체는 추상클래스인 Road 를 MainRoad 클래스와 AuxRoad 클래스가 상속받도록 정의했습니다. 물론 MainRoad와 AuxRoad는 구조가 다릅니다. 도로중심선(CenterLine)은 A 지자체에서만 정의하였고, 속성들이 서로 조금씩 다른 것도 있고 아얘 빠진 것들도 있습니다. (가상이니 심각하게 받아들이지 마시길...)

A 지자체에서 B 지자체에게 도로 데이터를 Shape 포맷으로 요청하면 어떻게 될까요. 당연히 B 지자체는 자신의 현재 구조 그대로 Shape 포맷으로 변환해서 넘겨줄 것입니다. 이 데이터를 받은 A 지자체는 다음과 같은 처리가 필요할 것입니다. 

- B 지자체에서는 MainRoad와 AuxRoad로 분리되어 있는 클래스를 Road 클래스로 합쳐야 합니다.
- RoadCover 는 RoadSurface와 동일하므로 클래스명만 수정합니다.
- CenterLine은 존재하지 않으므로 RoadSurface를 사용하여 자동 생성합니다.
- DateOpen는 MainRoad에만 있으므로, AuxRoad 클래스는 임의의 날짜를 부여합니다.
- Name은 동일하므로 그대로 가져옵니다.
- Admin 도 DateOpen 과 동일한 방식으로 처리합니다.

결국 데이터는 넘겨받았지만, 모든 클래스들을 일일이 검사하고, 수정을 거쳐야만 사용할 수 있게 됩니다. 새로 처음부터 만드는 것보다야 훨씬 편하지만, 엄청 많은 수고가 필요합니다. 넘겨받을 클래스의 수가 많을 수록 더 많은 노력이 필요하겠죠.

U 라는 사업체가 있어서 이들 도로데이터를 가져와서 사용하는 경우엔 어떨까요? 먼저 A 지자체에서 데이터를 받아와 데이터를 불러들이는 프로그램을 짰습니다. 이제 B 지자체에서 데이터를 받아오면 새로 프로그램을 짜야 합니다. 또다른 데이터를 받아오면? 또다시 새로운 프로그램을 짜야죠. 이처럼 모든 기관별로 응용스키마가 조금씩 다르기 때문에 매번 조금씩 달리 편집해서 사용해야 합니다. 물론 데이터를 제공해준다는 가정하에요. 예전에 내비게이션용 도로지도를 제작하던 어떤 업체 관계자는, 매 지자체별로 별도로 접촉해서 자료를 얻어야 했는데 공개하지 않는다는 곳도 많았지만, 기껏 공개를 해도 이처럼 많은 편집/가공이 필요하다고 푸념했던 기억이 납니다.

이처럼 현재 공개된 자료들은 모두 사용하려는 사람들이 구조를 일일이 검사하고, 변환하는 프로시져를 만들고, 테스트하는 과정을 걸쳐야만 사용할 수 있습니다. 심지어는 텍스트 정보만 제공되는 공공데이터 포털도 마찬가지입니다. 어떤 한 기관에서 제공하는 자료라면 그나마 다행이지만, 여러 기관의 데이터를 취합해야 하는 경우 정말 많은 자원이 소요됩니다. 게다가 담당자가 바뀌거나, 시스템이 변경되면 모든 과정을 새로 밟아야 합니다.

관리기관별로 데이터 내용 및 구조(응용스키마)가 다른 이유는 자신의 목적에 따라 시스템을 구축하기 때문입니다. 처음 측량을 통해 생산한 원시데이터는 동일하더라도, 시스템을 구축할 때는 내부의 목적, 사용하는 하드웨어/소프트웨어의 종류 등에 따라 달라질 수 밖에 없습니다. 응용스키마가 원래 그런 성격이니까요.

공통 응용스키마

그럼 이처럼 데이터 생산/관리 기관별로 구조가 다른 상태에서 어떻게 데이터를 교환해야 할까요? 이것이 "KSXISO 19118 지리정보 - 인코딩" 표준에서 다루는 문제입니다. 아래는 이 표준의 그림 1 "두 시스템간의 데이터 교환의 개요"입니다.

이 그림을 간단하게 설명하면, 다음과 같습니다.

1. 다수의 시스템에 대하여 공통 응용스키마 I 를 정의해야 한다.
2. 내부 DB는 이 공통 응용스키마를 적용한 임시 내부 데이터베이스 M_AI 를 생성한다.
3. 이 표준에 따른 인코딩 서비스 R을 사용하여 자료를 공통포맷으로 변환한다.
4. 이렇게 만들어진 파일/스트림을 상대측에 전송한다.

즉, 자산의 내부 DB를 그냥 변환하는 것이 아니라, 공통 응용스키마를 적용하고, 공통 포맷을 적용하여 변환해야 한다는 것입니다. 물론 읽어들일 때는 이 반대의 수순을 밟으면 되고요.

여기에서 볼 수 있는 것처럼, 데이터 공유에 있어 가장 중요한 것은 데이터 공개/유통에 참여하는 모든 참여자가 공유하는 "공통 응용스키마"입니다. 공통 응용스키마를 사용하고 그것이 정확하게 지켜지기만 한다면, 어떤 포맷을 사용해도 문제없이 데이터를 공유할 수 있습니다.

XML 인코딩

그런데, KSXISO 19000 표준군에서는 모든 종류의 공간정보 교환에 XML 포맷으로 인코딩 할 것을 권장하고 있습니다. KSXISO 19118 인코딩에서는 데이터를 XML로 변환하는 규칙을 제시하고 있고, KSXISO 19136 지리마크업언어(GML)에서는 이 XML 변환규칙을 보다 정확하게 규정하고 있으며, KSX1SO 19139 메타데이터 XML 구현에서는 메타데이터를 XML 로 변환하고 공유하는 규칙을 다루고 있습니다. 즉, 데이터 교환은 가능한한 XML 을 이용하라는 것입니다.

그런데 XML(또는 GML)은 데이터 그 자체일 뿐입니다. XML을 사용한다고 하여 데이터 교환이 순조롭게 이루어질 수 없습니다. 데이터의 내용 및 구조(응용스키마)의 공유, 준수가 필수적으로 뒤따라야 합니다.

XML 스키마는 XSD(XML Schema definition)로 정의됩니다. XSD는 말그대로 XML 파일의 스키마를 정의하는 문법입니다. 일반 XML 파일은 <tag1> </tag1> 등과 같은 형태로 태그만 맞춰주면 어떠한 데이터도 추가할 수 있으습니다. 그러나, XSD를 정의하면 XSD에 정의되어 있는 항목외에는 들어갈 수 없고, XML에 XSD 정의항목이 빠졌다면 오류가 발생하게 됩니다. 즉, XML 과 XSD는 쌍으로 움직이고, 일정한 내용과 구조를 갖출 수 있게 됩니다.

이와 같이 XML 은 XSD가 존재하기 때문에 데이터와 응용스키마를 함께 공개/교환 할 수 있습니다. Shape 등 다른 포맷은 응용스키마를 일치시킨다고 해도, 해당 데이터가 응용스키마에 일치하는지 여부는 별도의 어플리케이션을 작성해야만 검증할 수 있습니다. 하지만, XSD+XML은 이 자체만으로 데이터 구조의 일관성을 유지할 수 있습니다.

19118 인코딩 표준에서는 UML로 작성된 응용스키마를 XSD로 변환하는 규칙도 제공합니다. 다음 그림은 이 표준의 "그림 C.1 - XML 기반의 변환규칙" 입니다.(일부 수정) 이 그림에서 말하는 것은, 공간정보 응용스키마는 XSD로 인코딩하고, 공간데이터(응용데이터)는 이 XSD를 기준으로 XML(GML) 로 변환한 후, 이 두개의 파일을 모두 제공하라는 것입니다. 이것이 ISO 표준에 따르는 것이죠.

따라서, 국가공간정보포털과 같은 데이터 교환장소에는 데이터를 GML(XML) 포맷으로 제공하는 외에도 다음과 같은 응용스키마 관련 정보를 함께 제공해야 합니다. 이중 위의 두가지는 사람들이 편하게 이해하기 위한 용도이고, 마지막 XSD는 컴퓨터가 직접 해석하기 위한 용도입니다. (이 이외에도 메타데이터에 관한 내용도 XML로 제공해야 하지만, 이는 생략합니다.)

- 응용스키마 (UML)
- 데이터딕셔너리 - 응용스키마 객체의 상세 해설
- XSD - XML 용 스키마

기존 공간정보를 다루는 입장에서 볼 때, Shape 파일 등이 널리 사용되고 있으므로, 이런 포맷을 사용하는 것이 더 낫다는 의견도 있을 수 있습니다. 하지만, XML 포맷을 사용하면 다음과 같은 장점이 있어서, 단순한 Shape 파일보다 월등한 편의성을 누릴 수 있습니다.

- XML 포맷은 사람들도 어렵지 않게 읽을 수 있지만, 무엇보다 컴퓨터 처리에 좋다.

- XML을 처리하기 위한 다양한 라이브러리가 존재하기 때문에(오픈 소스도 다수 존재함)
  GIS 소프트웨어를 사용하지 않아도 일관성 검증이나 통계 등 간단한 데이터 처리가 가능하다.
    - XML Validator
    - XML DOM Parser

- XML 은 W3C에서 정의한 정보 교환/처리를 위한 표준으로 Web/IT 분야에 널리 사용되고 있으며,
  특히 공간정보를 모르는 사람들도 장벽없이 처리할 수 있다.

- XML 파일의 스키마(구조)를 정확하게 정의하는 XSD (XML Schema Defintion)를 함께 제공하면,   
  데이터 구조의 검증이 아주 쉬워진다. 즉, 일관된 구조가 100% 유지할 수 있다. 

이러한 장점이 있기 때문에, 데이터 공개/교환은 XML(GML)을 사용해야 한다는 것이 제 생각입니다. 아니 다른 포맷으로는 이러한 장점을 대체할 수 없으므로, 반드시 XML(GML)을 사용해야 합니다.

결론

이제 마무리를 지어야 할 때가 왔습니다. 제가 처음에 언급했던 "완벽한 데이터 유통체계"에 대해 다시 생각해보겠습니다. 

1. 개인정보보호, 보안 등 현행법에 저촉되지 않는 모든 데이터가 공개된다.
2. 모든 공개된 데이터의 상세한 내용및 구조가 별도의 데이터로서 공개된다.
3. 동일한 이름의 데이터에는 내용과 구조가 완전히 동일하다.
4. Machine Readable 한 포맷으로 공개된다.
5. 공개된 데이터의 구조도 함께 공개되며, 이 구조를 사용하여 자동 검증이 가능하다.
6. 이미 공개된 데이터가 일부 수정된 경우, 수정된 부분에 대해서 즉시 공개된다.
7. 공개된 데이터는 관련자에게 즉시 통지(notification)된다.
8. 해당 데이터의 사용자/기관은 (사람이 개입하지 않고) 자동으로 갱신된 데이터를 읽어오고, 
   이 데이터를 사용하여 자신의 데이터를 자동으로 수정한다.

동일한 데이터에 대해 공통 응용스키마를 갖도록 하고 이를 XSD, GML 로 공개하는 체계가 갖추어진다는 것은, 이 여덟가지 중에서 2,3,4,5 항목에 해당합니다. 1번 항목은 제도적으로 해결해야 할 부분이며, 6,7,8 항목은 공개된 데이터를 실시간으로 전달할 수 있는 시스템의 구축이 필요합니다. 물론 이러한 내용도 일부(개념적 수준에서는) 표준에 정의되어 있습니다. 

현재 국토지리정보원에서는 일부 지형지물에 대해 완공이 되는 즉시 측량을 실시하는 실시간 갱신작업을 실시하고 있는 것으로 압니다. 그런데, 이러한 측량이 완료되는 시점에서 국민에게 전달될 때까지의 시간 - 즉, 네이버/다음 등의 포털지도에 나타나기 까지의 시간은 최소 6개월 이상 걸릴 것으로 생각됩니다. 제가 지금까지 말씀드린 "데이터의 내용 및 구조"라고 통칭한 이러한 기술을 적용하여, 정말 실시간으로 데이터를 공유할 수 있는 날이 빨리 오기를 소망합니다.

민, 푸른하늘

ISO/TC 211에서 발간한 공간정보 표준 가이드(ISO_TC_211_Standards_Guide)를 번역했습니다.

사실 번역을 시작한지는 꽤 된 것 같습니다. 적어도 3년 이상된 것 같은데, 생각날 때마다 찔끔찔끔 하다가, 이번에는 꼭 마치겠다는 각오로 끝냈습니다.

아직 모자라는 부분이 많습니다. 표준에 대해 모르는 부분도 많다보니, 제대로 번역이 안된 부분도 있고, 아직 제대로 검토를 하지 않아서 오자나 탈자도 많을 겁니다. 그렇다고 퇴고를 언제 할지도 모르는데 무작정 둘 수 없어서 공개합니다. 

이 글의 원본이 2009년에 나왔습니다. 벌써 9년이나 흘렀네요. 그러다보니 개요부분에 현실과 약간 멀어진 내용도 있고, 소개된 표준도 현실을 반영하지 못한 부분도 있습니다. 

원본은 아래와 같습니다. 영어 원문과, 일본 국토지리원에서 번역한 일본판 원문입니다. 내용은 거의 비슷하기 때문에 두가지 버전을 참고하면서 번역했습니다. 구글 번역기의 도움을 많이 받았습니다.

ISO_TC_211_Standards_Guide.pdf

ISO_TC_211_Standards_Guide_Japanese.pdf

아래는 제가 번역한 한글판입니다. 

ISO_TC_211_표준_가이드.pdf

아무튼 조금이라도 도움이 되길.

민, 푸른하늘

Aaron Skonnard

DevelopMentor

May 2003

Summary : XML Schema 정의 언어(XSD)는 include와 import와 같은 포함 메커니즘을 통해 코어 라이브러리의 재사용 및 장기 관리를 가능하게 한다. 아울러 스키마 정의를 여러개의 파일 및 네임스페이스로 분할하여 관리할 수 있다. 오늘날 사용되는 프로그래밍 언어 방식의 유형 계층을 모델링할 수 있는 스키마 라이브러리의 설계방법에 대해 배워보자.

개요

XML Schema 정의 언어(XSD)는 XML 문서를 설명하는 언어중 대세가 되고 있다. XML Schema는 simple 및 complex 유형을 정의할 수 있다. Simple 유형은 문자만의 요소/속성에 맞춤식 값공간을 정의할 수 있으며, Complex 유형은 이러한 값 공간을 배열하여 구조체를 만들수 있다. XML 스키마는 매우 표현이 뛰어나고 XML 기반 응용에 강력한 서비스를 제공할 수 있다. 특히 웹 서비스 도메인에 유용하다. 이러한 서비스로는 검증, reflection, 자동 직렬화(type mapping) 원격 메소드 발동 등이 지원되며, XML을 위한 IntelliSense와 같은 기능을 잘 지원해줄 수 있다.

나의 첫번째 글 XML Schema의 이해에서는 핵심적인 XSD 언어 구성과 사용법에 대해 다루었다. XSD는 사실 이 글에서 다루었던 것 보다 훨씬 더 강력한 기능을 제공한다. Complex 유형 정의에서는 확장이나 제한을 사용한 유도 유형을 지원함으로써, complex 유형 계층을 정의할 수 있다. complex 유형 계층이 있으면, 인스턴스 문서에서 대체 기법을 사용할 수 있게 된다. XSD는 또한 schema 정의를 여러개의 파일과 네임스페이스로 분할 한 뒤, include 혹은 import 하는 방법을 사용함으로써, 재사용과 간편한 유지보수를 가능하게 한다. 이러한 좀더 고급 설계중심의 주제가 이 글의 주제이다.

유형 계층 (Type Hierarchies)

XML Schema의 이해에서 XSD에 내장된 simple 데이터 유형의 종류를 보였다. (그림 1) 이들 데이터유형은 유형 계층으로 정의된다. 그림 1에서 화살표는 제한에 의한 유도(derivation by restriction)를 나타낸다. 즉, byte는 short을 제한함으로서 유도되는데, 이는 byte의 값공간이 short의 값공간의 부분집합이라는 의미이다. 이러한 계층성을 유형간의 관계로 생각할 수 있다. 예를 들어, 제한에 의한 유도를 사용할 때, 유도된 유형의 인스턴스는 기반 유형의 인스턴스이기도 하다는 뜻이다. (즉, byte는 short의 일종이며, short은 int의, int는 long의 일종 등등이다.)

<그림 1> XSD 내장 데이터유형

XSD를 사용하면 이 계층을 확장하여 맞춤형 simple 유형을 정의할 수 있다. 새로운 simple 유형을 정의할 때, 기본적으로 내장 데이터유형으로부터 유도된 새로운 유형을 정의하고, 하나 이상의 facet을 제한하게 된다. 다음의 예에서 tns:PersonAge 는 xsd:byte로부터 유도하여, 값공간을 0에서 100까지로 제한한다.

이제 tns:PersonAge 와 xsd:byte 사이에는 유형 관계가 있다. tns-PersonAge는 xsd:byte의 유효한 인스턴스이기도 하며, xsd:byte는 xsd:short 의 유효한 인스턴스이고, xsd:short는 xsd:int의 유효한 인스턴스인다. 이러한 관계는 제한을 통한 유도 유형에서는 항상 성립한다. Simple 유형의 제한에 관한 자세한 내용은 XML Schema의 이해를 참고하라.

Complex 유형의 경우, 위의 예에서 보인 것처럼 유형 계층을 정의할 때 제한 혹은 확장에 의하여 유형을 유도할 수 있다. 하지만, 제한과 확장을 동시에 적용할 수 없다. 하나의 유형정의에서는 제한과 확장 두가지 중 하나만 사용하여 유도할 수 있다. 따라서 기본 유형을 제한하고 확장하고 싶다면, 두번을 별도로 유형 정의해야 한다.

제한에 의한 Complex 유형 유도

Simple 유형과 마찬가지로, 제한에 의하여 Complex 유형을 유도할 수 있다. 이는 기존의 Complex 유형으로부터 그 구조체를 형성하는 요소나 속성을 제한함으로써 새로운 Complex 유형을 유도할 수 있다는 것이다. 예를 들어, 사람을 표현하는 아래의 Complex 유형을 살펴보자.

다음의 XML 문서는 tns:Person 유형의 유효한 인스턴스를 담고 있다. 참고로 로컬 요소 및 속성은 정규화되어 있지 않다. (로컬 요소와 속성은 기본이 비정규화(unqualified)임) 또한 age 요소는 생략되어 있으며, phone 요소는 세번 들어가 있다. 이는 모두 유형 정의에서 허용된 것이다.

만약 tns:PersonType을 구성하는 일부 요소 및 속성을 제한하려고 한다면, xsd:complexContent와 xsd:restriction 요소를 사용하여, 제한(restriction)에 의한 새로운 complex 유형을 유도할 수 있다.

xsd:complexContent 요소는 해당 complex 유형이 다른 complex 유형으로 유도된 것을 나타낸다. xsd:restriction 요소는 원래 제한하기 전의 기본 유형과, 모든 기본 유형(base type)의 particle(compositor, 요소 정의, wildcard 등)에 대한 새로운 정의를 포함한다. 이렇게 할 때에는 반드시 기본유형의 모든 particle을 나열해야 하며, 기본유형의 부모가 있을 경우, 해당 내용도 포함시켜야 한다.

기본유형은 두가지 방법으로 제한할 수 있다. 한가지는 값공간을 더 좁게 제한하는 것. 또다른 하나는 particle의 출현빈도(occurrence constraint)를 강하게하는 것이다. "값공간을 좁계"하는 것은 기본 유형에서 사용된 simple 유형으로부터 유도된 다른 유형으로 유형을 변경하면 된다. 예를 들어, tns:PersonType에서 age 요소는 xsd:byte 유형이다. age 요소의 유형을 tns:PersonAge으로 변경하면 age의 값 공간을 더 제한할 수 있다.

base 유형의 출현빈도 제한을 더 강하게 지정하는 방식으로 제한할 수도 있다. "강한 출현빈도 제한"이란, 새로운 출현빈도 제한이 기본유형의 출현빈도 제한 범위이내에 한다는 것을 의미한다. 예를 들어, 위의 phone 요소는 최소 1번에서 최대 5번 등장할 수 있다고 정의되어 있다. 유도 유형에서 이 요소를 제한 할 때, phone 요소의 minOccurs를 1보다 작게하거나, maxOccurs를 5보다 크게 바꿀 수는 없다. 하지만, 아래처럼 두면 해당요소가 반드시 2번 나타나도록 횟수제한을 강하게 하고 있다. (여전히 기본 유형의 횟수제한에 유효하다)

이러한 방식으로 작동되므로, 어떤 요소가 기본 유형에서 필수로 정의되어 있다면(name, phone 등), 유도 유형에서는 이를 삭제시킬 수 없다. (참고 : minOccus 와 maxOccurs의 기본값은 1이다) 하지만, 기본 유형에서 선택적 요소인 경우(age), maxOccurs=0으로 두어 출현하지 못하도록 막거나, minOccurs=1로 두어 필수 요소로 만들 수 있다. 여기에서도, 유도 유형의 횟수제한은 기본유형에서 정의된 범위 내에 있을 때만 적법하다.

속성에서도 이와 동일하다. 속성이 기본유형에서 선택적일 경우(기본값임), 필수로 만들거나, 금지시킬 수 있다.('prohibited'는 제한에서만 적용되며, 그렇지 않은 경우 무시됨) 예를 들어 다음의 속성 정의는 유도 유형에서 id 속성을 금지시키는 방법을 나타낸다.

이제 제한된 complex 유형의 완전한 예를 살펴보자, 아래의 예제는 xsd:string을 pattern facet으로 제한한 새로운 simple 유형을 정의하고 있다. 이들 유형은 base 유형에 사용되는 일부 요소및 속성 정의를 제한하는데 사용된다. 아울러 여러 요소 및 속성 선언의 횟수제한을 제한하고 있다.

이 예에서 우리는 새롭게 정의한 simple 유형(tns:PersonAge와 tns:Phone)을 사용하여 age와 phone 요소의 값공간을 제한하였다. 아울러 age 요소에 대해 횟수제한을 강화하였다. (이제 필수요소가 됨) phone 요소는 이제 정확하게 한번만 출현해야 하고, id 속성의 경우 선택적이 아니라 금지되었다. 아래의 문서는 tns:RestrictedPerson의 유효한 인스턴스를 담고 있다.

이 새로운 유형의 모든 측면은 기본 유형을 제한한 것이므로, tns:RestrictedPerson의 유효한 인스턴스는 tns:Person의 유효한 인스턴스이기도 하다. 그러나 그 반대는 참이 아니다. tns:Person의 유효한 인스턴스라고 하여 반드시 tns:RestrictedPerson의 유효한 인스턴스는 아니다.

확장에 의한 Complex 유형 정의

제한에 의한 유도가 중요하고, XML 스키마의 핵심요소이기는 하지만, 대부분의 프로그래밍 언어에서는 지원되지 않는다. 따라서, 스키마 정의를 프로그램 유형으로 매핑할 때, 마지막 예제에 있는 대부분은 프로그램의 클래스로 자연스럽게 변환되지 않는다. 하지만 확장에 의한 유도는 대부분의 객체지형 프로그래밍 언어에서 상당히 널리 사용되며, XSD에서도 지원된다.

Complex 유형만이 확장에 의한 유도가 지원된다. (즉, 기존의 simple 유형을 확장하여 새로운 simple 유형을 만드는 것은 불가능하다.) 하지만, 기존의 simple 유형 또는 complex 유형을 확장하여 새로운 complex 유형을 유도할 수 있다. 어느 유형으로부터 유도하는지는 xsd:simpleContent 또는 xsd:complexContent 요소를 사용하여 지정하며, xsd:extension을 중첩사용하여, 확장에 의한 유도를 표시한다.

simple 유형으로부터 확장에 의한 유도를 할 때에는, 새로운 유형에 속성 만 추가할 수 있다. (요소를 추가하면 더이상 simple 유형이 아니다.) 다음의 예는 기존의 simple 유형인 tns:Phone 으로부터 속성을 추가하여 새로운 complex 유형인 tns:PhoneWithLabel을 정의하는 방법을 나타낸다.

xsd:simpleContent는 xsd:complexType의 자식으로서 나타난다. 이는 새로운 유형의 내용이 character 데이터만 있고 다른 child 요소가 없음을 표시한다. 이 경우, 유형에 속성을 추가만 했으며, 이로 인해 새로운 유형은 complex 유형이 되었다. (simple 유형은 어떠한 구조도 가질 수 없다. 속성조차). 아래는 tns:PhoneWithLabel 의 유효한 인스턴스이다.

이미 존재하는 complex 유형으로부터 확장하는 것도 동일한 방법으로 가능하다. 다만, xsd:complexContent를 사용하여, 새로운 유형의 내용에 character 데이터 외에도 다른 내용(예를 들어 추가적인 child 요소)이 존재함을 표시한다. 아래의 예는 tns:Person으로부터 새로운 complex 유형을 유도하는 방법을 나타낸다.

확장에 의하여 유도할 때에는 base 유형에 어떠한 변화도 만들 수 없다. base 유형에 새로운 particle을 추가하는 것만 가능하다. base 유형을 변경시킬 수 없으므로, 제한에 의한 유도에서처럼 particle을 재정의 할 필요가 없다. 그 대신, 그냥 새로운 내용을 정의하면 base 유형의 내용의 뒤에 추가된다. 새로운 내용은 논리적으로 base 유형 내용의 뒤에 추가되어, 아래와 같이 마치 두개의 내용 모델이 하나의 xsd:sequence 요소 내에 둘러싸여진 것처럼 작동된다. 

다음은 tns:ExtentedPerson의 유효한 인스턴스의 예이다.

제한에 의한 유도와는 달리, 확장된 유형의 인스턴스는 base 유형의 유효한 인스턴스가 아닌 경우가 많다. 여기에서 보는 것처럼 tns:extPerson은 절대 tns:Person의 유효한 인스턴스가 아니다.

 There are a few restrictions to derivation by extension when it comes to xsd:all compositors. If a complex type uses xsd:all as its top-level compositor, you can't extend it by adding new particles—you can only add attributes in this case. Also, you can't extend another complex type with an xsd:all unless it has an empty content model. 확장에 의한 유도에서 xsd:all compositor를 사용할 때에는 몇가지 제한이 있다. complex 유형이 최상위 compositor로서 xsd:all을 사용하면, 새로운 particle을 추가하는 방식으로 확장할 수 없다. - 이 경우에는 속성 추가만 가능하다. 또한, xsd:all이 있는 complex 유형은 내용모델이 비어있지(empty) 않는한 확장할 수 없다.

유도 방지(Blocking Derivation)

'봉인(sealed)' 클래스 정의와 비슷하게, 특정한 유형으로부터 새로운 유도를 방지하고자 할 경우가 있다. XSD에서는 xsd:complexType에 final 속성을 통하여 가능하다. (참고로, substitution 구릅을 사용할 때 요소선언에서 final 속성을 사용할 수도 있다.) final을 사용하면, 특정유형으로부터 유도 메커니즘이 금지된다. final 속성의 값은, extension, restriction, #all 등 세가지이다. 예를 들어, 다음의 complex 유형 정의는 tns:Person 기본유형으로부터 제한에 의한 유도 및 확장에 의한 유도 모두를 금지한다.

아래의 예와 같이 xsd:schema에 finalDefault 속성을 사용하면, 스키마 전체에서 final 속성을 기본값으로 지정할 수 있다.

이렇게 하면 기본값으로, complex 유형간에서 제한에 의한 유도가 허용되지 않는다. 위에서 보인 final 속성을 사용하여 이 설정을 덮어씌워야만 변경이 가능하다.

추상 유형(Abstract Types)

대부분의 객체지향 언어에서는 추상 유형을 정의할 수 있다. 이 문맥에서 추상유형이란 인스턴스화 할 수 없는 것을 말한다. 추상 base 클래스와 추상 base 인터페이스가 이러한 유형의 예이다. One purpose of abstract types is to define a contract that other derived types will implement. 추상유형의 목적은 다른 유도 유형이 수행된다는 계약을 정의하는 것이다. This makes it possible to build applications around abstract interfaces, supporting numerous possible implementations. The assumption is that some derived type will be substituted for the abstract type at runtime. 

아울러 XSD는 추상 complex 유형을 정의할 수 있다. 아래와 같이 xsd:complexType 요소에 abstract 속성(boolean)을 사용하면 된다.

이 속성의 기본값은 false로서, complex 유형은 구체적이라는 것이다. 추상 스키마 유형은 XML 인스턴스 문서에서 유형으로 나타날 수 없다는 것을 의미한다. 그대신 추상유형이 있어야 할 곳에 반드시 유도된 유형이 대체되어 나타나야 한다.

xsi:type을 사용한 대체(substitution)

유형계층을 정의하면 좋은 장점은 유도된 유형의 인스턴스를 대체할 수 있는 능력이다. 객체지향 기술에서 폴리모피즘과 같이, base 유형이 와야할 곳에 유도 유형을 대체할 수 있다. XML 문서에서 이를 실행할 수 있는 방법중 하나가 xsi:type을 사용하는 방법이다.

xsi:type을 사용하면 요소의 유형을 명시적으로 지정할 수 있다. 이렇게 함으로써 스키마에서 요소선언이 없을 경우에 조차, 어떤 요소가 특정 유형이라고 주장하는 것이 가능해진다. 이 속성은 유도된 유형의 인스턴스를 기반유형이 와야 할 곳에 사용할 때 가장 널리 사용된다. 이 경우, 스키마 프로세스는 xsi:type 속성에서 지정한 유형이 기대된 기반유형으로부터 유도되는 것을 보증한다. 예를 들어, 아래의 tns:Family라는 complex 유형 정의를 고려해 보자. 이 유형은 tns:Person 유형의 여러개의 person 요소 목록을 포함하고 있다. 

아래의 문서는 tns:Family의 유효한 인스턴스를 담고 있다. 주목할 점은 tns:RestrictedPerson 과 tns:ExtendedPerson 의 인스턴스가 tns:Person의 인스턴스가 와야할 곳에 대체되었다는 점이다.

이상과 같이 이런 대체 스타일은 유형이름에 기반하며, 요소 이름에 기반하는 것이 아니다. 즉, 유형을 결정할 때 요소 이름만 봐서는 안된다는 것이다. 하지만 XSD에는 요소 이름에만 완전히 기반하는 대체유형도 존재한다.

대체 그룹(Substitution Groups)

대체그룹은 요소기반의 대체를 허용한다. 대체그룹을 형성하려면, 전역적 요소선언이 그룹의 'head'로서 작용한다. (어떤 전역 요소이든 특별한 무언가가 필요없이 'head'로서 작동한다.) 그래서 다른 전역요소 선언은 substitutionGroup 속성을 사용하고 아래와 같이 head 요소의 이름을 지정함으로써, 대체 그룹에 참여할 수 있다. 

대체그룹의 멤버는 반드시 head 요소의 유형에 관련되어야 한다. 즉, 멤버요소는 head 요소와 동일한 유형일 수도 있고, 제한/확장 유형일 수도 있다. 이 법칙은 대체된 요소가 head 요소의 위치에 사용될 때 의미가 있다는 것을 보장한다.

For example, with the above substitution group in place, we can change the complex type definition for tns:Family to reference the global tns:person element: 예를 들어, 위의 대체그룹에서 우리는 tns:Family에 대한 complex 유형 정의를 전역적 tns:person 요소를 참조하도록 변경시킬 수 있다.?

그러면 다음과 같이 이 위치에 tns:person 대체그룹의 어떤 멤버도 대체할 수 있다.

주목할 점은 tns:person, tns:resPerson, tns:extPerson은 모두 전역 요소로서 스키마의 target 네임스페이스에 의해 정규화(qualified)되어야 한다는 점이다. 아울러, 요소기반의 대체를 사용하기 때문에, 더이상 유형정보를 지정하기 위해 xsi:type 을 사용할 필요가 없다는 점도 주목해야 한다. 이제 요소의 유형은 이름만으로부터 끌어낼 수 있다.

대체 방지(Blocking Substitution)

유도와 마찬가지로, 특정 유형에서 대체가 사용되는 것을 막고 싶거나 대체그룹에서 요소가 사용되는 것을 막고 싶을 경우가 있을 수 있다. xsd:complexType 또는 xsd:element에 block 속성을 사용하면 특정 유형/요소에 대한 대체를 막을 수 있다. The block attribute allows you to specify what derived types/elements may be used in place of the type/element at hand. block 속성을 사용하면, 유도된 유형/요소가 직접적으로 그 유형/요소에 사용될 것인지 지정할 수 있다. block 속성에 허용되는 값은 extension, restriction, substitution, #all 등이다. 예를 들어 아래의 complex 유형 정의는 확장된 유형을 tns:Person이 필요한 자리에 대체될 수 없도록 방지한다.

또한 xsd:schema 요소에 blockDefault 속성을 사용함으로써, block 속성에 대한 기본값을 지정할 수 있다. 아래의 예는 이 스키마에서 기본값으로 모든 종류의 대체가 금지된다. (특별한 complex 유형이 block 속성을 사용하여 이 설정을 바꾸지 않는한)

xsd:complexType과 마찬가지로, xsd:element의 abstract 속성과 final 속성을 사용하여, 대체그룹에서 요소가 어떻게 사용될지를 제어하는 것도 가능하다.

재사용(Reuse)

스키마 라이브러리를 설계할 때, 아마도 다양한 스키마에서 공유되어야 할 필요가 있는 글로벌 유형이 있을 것이다. 이러한 경우, 이러한 유형을 별도의 스키마 파일에 정의를 한 후, 다른 스키마 파일에 include 혹은 import 시키고 싶을 수 있다. 여러개의 스키마 파일로 부터 스키마를 만드는 것은 매우 흔한 일이다.

XSD에서는 xsd:include와 xsd:import 요소를 통해 이러한 재사용이 가능하다. xsd:include는 별도의 파일에 있는 스키마를 포함시킬 수 있다. 이 경우, 두개의 스키마 파일의 target 네임스페이스가 동일해야 한다. 하지만, target 네임스페이스가 없는 스키마 파일을 include 시키는 것도 가능하다. 이 경우, 포함된 construct들은 새로운 target 네임스페이스의 일부가 된다. 아래는 xsd:include의 작동방법 예시이다.

xsd:include가 어떤 경우에는 편리할 수 있지만, 실재로는 xsd:import가 더 널리 사용된다. xsd:import는 다른 네임스페이스에서 새로운 스키마로 유형을 'import'시킬 수 있다. 이경우, import된 유형은 여전히 원래의 네임스페이스에 존재하지만, 새로운 네임스페이스에서 새로운 유형을 구축하는데 사용될 수 있다. 예를 들어, 다음의 스키마 정의에는 tns:Person 유형이 포함되어 있다.

우리는 이 스키마를 새로운 스키마로 import하며, 이 유형을 기본유형으로 하여 새로운 complex 유형을 정의하는데 사용할 수 있다.

다른 네임스페이스에 있는 유형을 import 할 때에는 제한에 의한 유도(derivation by restriction)을 주의깊게 사용해야 한다. import된 Complex 유형에 정규화된(qualified) 지역요소가 있고(즉, elementFormDefault="qualified"), 새로이 제한된 complex 유형을 정의할 경우, 지역요소의 네임스페이스를 바꾸게 됨으로써, 제한이 invalid하게 된다. import 된 유형의 지역 요소가 비정규화 요소일 경우, 새롭게 제한된 유형이 네임스페이스를 변경하지 않으므로, 이런 일이 발생하지 않는다.

결론

As you can see, XSD is a powerful and flexible language capable of representing many of the type hierarchies commonly used in today's object-oriented systems. Even better, XSD makes it possible for applications to take advantage of type relationships through XML substitution techniques. This makes it possible to model not only the type hierarchies themselves, but also how they're used in practice. 이상과 같이 XSD는 현재 객체지향시스템에서 널리 사용되는 유형 계층의 상당 부분을 표현할 수 있는 강력하고도 유연한 언어이다. 아울러, XSD를 사용하면 응용에서 XML 대체기법을 통해 유형 관계를 이용할 수 있다. 따라서, 유형 계층화 그자체 뿐만아니라, 실재로 어떻게 사용되는지를 모델링할 수 있다.

XSD의 포함 메카니즘(즉, include 와 import)를 사용하면 핵심 라이브러리를 재사용하고 장기간 유지관리가 쉽게 된다. XSD가 완벽한 건 아니지만, 현재 사용되는 다양한 프로그래밍 언어 고유의 유형을 모델링할수 있는 스키마 라이브러리를 설계하기 위한 확고한 기반을 제공한다. XML 스키마에 관한 좀 더 많은 정보는 Essential XML Quick Reference 등 아래에 있는 기타 문헌을 참고하라.

참고문헌

XML Schema Part 0: Primer 

XML Schema Part 1: Structures 

XML Schema Part 2: Datatypes 

Essential XML Quick Reference

===

원문 : https://msdn.microsoft.com/en-us/library/aa468549.aspx

Aaron Skonnard
DevelopMentor 

 March 2003 

적용분야 :
    Type systems
    XML Schema definition language (XSD)
    Web Services development 

요약 : XML Schema는 XML 프로세싱의 미래에서 핵심적 역할을 담당할 것이다. 특히 웹서비스의 경우, 고수준의 추상화의 바탕이 되는 중요한 기둥중 하나가 될 것이다. 이 글은 XML Schema 정의 언어의 사용법을 좀더 자세하게 설명한다. (인쇄시 22쪽)

개요(Introduction)

1+2 = ?

소프트웨어에서 이러한 문제의 답을 내는 데에는 유형(type) 시스템이 필요하다. 프로그래밍 언어는 품질이 높은 코드를 생산하기 위한 임무를 간단히 하기 위하여 유형 시스템을 사용한다. 유형 시스템은 여러가지 유형과 연산을 정의하며, 개발자들은 이들을 선택하여 자신의 프로그램에 적용한다. 유형은 값 영역, 다른 말로하면 가능한 값의 집합을 정의한다. 예를 들어 위의 연산이 숫자형(numeric) 유형이라면 답은 3이 될것이다. 하지만 문자열(string)의 경우 + 연산자의 정의에 따라 다르겠지만, "12"가 될 수 있다.

유형시스템의 중요한 잇점중 하나는 컴파일러가 코드에 에러가 있는지 미리 알 수 있어, 많은 오류를 미리 피할 수 있다는 것이다. 컴파일러는 또한 유형 시스템 정보를 사용하여, 주어진 유형에 따른 연산 코드를 생성할 수 있다. 또한 컴파일러와 실행프로그램은 특정한 유형에 대한 메모리 할당 방법을 결정하는데 유형시스템에 의존하며, 그 결과 개발자들은 지겹고 까다로운 문제를 잊어버릴 수 있다.

많은 언어와 실행프로그램은 프로그램이 실행될 때 유형 정보를 검사하는 것도 가능하다. 프로그래머는 어떠한 사건에서든 유형의 특성을 질문하고, 그 답에 따라 결정을 내릴 수 있다. 이와 같이 실행시 유형정보를 검사하는 기법을 일반적으로 reflection이라고 한다. Reflection은 Microsoft®.NET Framework 와 Java와 같은 주류 프로그램밍 환경에서 중요한 역할을 담당한다. 즉, 가상머신(CLR(common language runtime)이나 JVM)은 보안, 가비지 청소, 직렬화, 원격 메소드 실행, 웹서비스 통합 등 대부분의 프로그램이 필요한 추가 서비스를 제공함으로써, 프로그래머의 수많은 고민을 효과적으로 줄여준다.

<그림 1> 유형 정보의 장점

또한 잘 정의된 유형 시스템과 reflection을 사용하면 언어와 잘 맞는 더 나은 도구를 제작할 수 있다. Developers have quickly grown used to things like Microsoft® Intellisense®, code completion, and those handy red squiggles that greatly speed up the development process. 전체적인 좋은 유형 시스템은 많은 재미있는 장점(그림 1 참고)을 제공하며, 거의 모두 당연히 받아들이기는 쉽지만 없을 경우 엄청나게 필요할 것이다.

XML 1.0은 합리적인 유형 시스템이 존재하지 않는 언어의 좋은 예이다. 유형 시스템이 없으면 XML 1.0 문서에 포함된 정보는 오직 문자로만 취급될 수 있다. 이렇게 되면 개발자들은 미리 "진짜 유형"이 무엇인지 파악해야 하며, 강제로 코드에 넣어 구현해야 할 것이다.

XML Schema 정의 언어(XSD)는 XML 처리 환경을 위한 유형 시스템을 제공한다. 간단히 말해 XML Schema가 있으면 사용하고자 하는 유형을 서술하는 것이 가능하다. XML Schema 유형에 적합한 XML 문서를 instance 문서라고 하는 경우가 많은데, 이는 전통적인 객체지향체계에서 클래스(class)와 객체(object)의 관계와 상당히 유사하다. (그림 2 참고). 이는 DTD(Document Type Definition)의 작동 방법론과 개념적으로 상당한 차이가 있다. XML Schema는 전통적인 프로그래밍 언어나 데이터베이스 시스템 등에 매핑할 때 훨씬 더 유연성이 많다. 이러한 환경에서 XML Schema는 DTD의 사용을 대부분 대체하였다.

<그림 2> 객체지향과 XML 스키마 개념

XML Schema는 그림1에서 나타낸 모든 장점을 제공해줄 수 있다. (단 XML에 대해서만) XML Schema 유형 정보를 포함한 논리적 XML 문서는 PSVI(post schema-validation Infoset : 스키마 인증 Infoset?)이라고 한다. PSVI를 사용하면, 다른 프로그래밍 환경과 마찬가지로 프로그램 실행중에 XML Schema 기반의 reflection을 수행할 수 있다. 전체적으로 XML Schema는 XML 프로세싱의 미래에서 핵심적 역할을 담당할 것이다. 특히 웹서비스의 경우, 고수준의 추상화의 바탕이 되는 중요한 기둥 중 하나가 될 것이다. 이 글은 XML Schema 정의언어의 사용법에 대해 좀더 자세하게 설명하는 글이다.

Datatypes: Value and Lexical Spaces

XML Schema는 개발자들이 사용할 수 있는 내장 데이터유형이 제공된다. (W3C XML Schema Part 2: Datatypes 페이지에 유용한 그림이 있음) 이들 모든 유형은 http://www.w3.org/2001/XMLSchema 네임스페이스에서 찾을 수 있다. 각각의 유형은 정의된 값 공간이 있다. 유형의 값 공간은 간단히 해당 유형의 인스턴스에 사용할 수 있는 값의 집합이다.

<그림 3> byte 유형의 값공간

예를 들어 XML Schema는 byte라는 이름의 내장 유형이 있다. byte의 값 공간의 -128 부터 127까지 이다. 또다른 예로 XML Schema boolean 유형은 값 공간이 훨씬 간단하다. 즉 true 와 false 두가지 값만으로 구성된다. 전체적으로 44개의 내장유형이 있으며, 각각 값 공간이 달라서 다양한 데이터 모델링 수요를 충족시킬 수 있다. 

그림 4는 많은 내장 유형이 다른 유형의 값 영역의 부분집합으로 정의됨을 표시한다. 이를 제한에 의한 유도(derivation by restriction)이라고 한다. 예를 들어 byte의 값 공간은 short의 값 공간의 부분집합이며, short의 값 공간은 int 값 공간의 부분집합, int의 값 공간은 long의 값 공간의 부분집합... 등이다. 따라서 기본적인 집합 이론에 따라 유도된 유형의 인스턴스는 또한 상위 유형의 인스턴스이기도 하다. (엄밀하게 말해 이들은 모두 anySimpleType 자체의 부분집합이다.)

Although programming languages use value space information to figure out how much memory will be needed to represent values, developers seldom need to worry about representing them as text. 프로그래밍 언어가 값공간 정보를 사용하여 값을 표현하는데 필요한 메모리 양을 파악하지만, 개발자들은 값들을 그냥 문자로 표현해도 크게 걱정할 필요가 없다. 하지만 XML을 사용하면 해당 인스턴스가 XML 1.0 파일로 직렬화될 가능성이 높다는 사실을 무시할 수 없으며, 이때 값에 대한 사전적 표현이 필요하게 된다. 모든 XML Schema 프로세서가 이를 독립적으로 결정한다면 상호운영성이 보장되지 못하게 될 것이다. 따라서 각 유형의 값공간을 정의함과 함께 XML Schema는 허용되는 사전적 표현도 정의하고 있다.

<그림 4> 유형 부분집합

예를 들어, 불리언 true 값은 "ture" 혹은 "1"로 표현할 수 있으며, 불리언 false 값은 "false" 또는 "0"으로 표현할 수 있다. double 형 10 은 "10", "10.0", "10.0000", 심지어는 "0.01E3"로도 표현할 수 있다. 또한 date 형의 값인 2003년 1월1일은 "2003-01-01"로 사전적으로 표현할 수 있다. 각각의 유형에 대해 사전적 형태(및 모든 변화된 형태)를 표준화하면 개발자들이 직렬화방법의 복잡성을 무시하면서 값들을 자유롭게 처리할 수 있다.

네임스페이스에서 유형 정의하기

대부분의 프로그래밍 언어는 내장 유형도 제공하지만, 개발자가 자체적으로 유형을 정의할 수 있다. 이를UDT(user-defined types : 사용자 정의 유형)라고 한다. UDT를 정의할 때 대부분의 언어는 네임스페이스도 함께 정의함으로써 동일한 이름을 사용하는 다른 UDT와 우연히 충돌하는 것을 방지할 수 있도록 하고 있다. XML 네임스페이스의 작동방법에 관한 내용은 XML 네임스페이스의 이해를 참고하라. 그림 5는 C# 네임스페이스 정의와 XML Schema 정의를 비교한 것이다. 보시는 바와 같이 XML 스키마도 네임스페이스 내에서 유형을 정의할 수 있다.

<그림 5> 네임스페이스에서의 데이터 유형 정의

xsd:schema 요소는 네임스페이스에 무엇이 포함되는지 범위를 정하고, targetNamespace 속성은 네임스페이스의 이름을 지정한다. 예를 들어, 다음의 XML Schema 템플릿은 http://example.org/publishing이라는 새로운 네임스페이스를 정의한다.

xsd:schema 요소 내에 (직계 자손 immediate child로) 정의된 모든 것은 글로벌로 간주되므로, 자동적으로 target 네임스페이스에 연결된다. 위의 예에서는 http://example.org/publishing 네임스페이스에 AuthorId, AuthorType, author, authorId 등 4가지가 정의되어 있다. 그 결과 누군가 이러한 것을 하나라도 참조한다면, 네임스페이스 정규화 이름(namespace-qualified name)을 사용해야 한다.

네임스페이스 정규화 이름을 사용하려면 스키마의 targetNamespace값에 사상되는 또다른 네임스페이스 선언이 필요하다. 위에서 'tns' 접두사 선언이 이러한 목적이다. 따라서 나의 스키마에서 정의던 무엇인가를 참조하려면, 위의 예와 같이 'tns' 접두사를 사용하면 된다.

xsd:schema 요소내에서는 두가지 유형을 정의할 수 있다. simple 유형(xsd:simpleType)과 complex 유형(xsd:complexType)이다. Simple 유형은 텍스트만 들어가는 요소나 속성만 넣을 수 있다. Simple 유형은 구조를 정의할 수 없고 값 공간만 정의할 수 있다. 여러개의 속성이 있거나 하위 요소가 있는 등 추가적인 구조가 필요한 경우에는 complex 유형을 정의해야 한다.

유형정의와 함께 (xsd:element를 사용하여) global 요소와 (xsd:attribute를 사용하여) global 속성을 정의하고 유형으로 할당할 수 있다. 위의 예에서는 author라는 global 요소와 authorId라는 global 속성을 정의하였다. 이들 constructs도 global이기 때문에 인스턴스 문서에서 사용하려면 target 네임스페이스를 지정해야 한다.  다음의 XML 문서에는 위에서 정의한 author 요소의 인스턴스가 들어있다.

또한 다음 XML 문서는 global 속성 authorId를 포함하고 있다.

또한, http://www.w3.org/2001/XMLSchema-instance 네임스페이스의 type 속성을 사용하면, 인스턴스 문서에서 요소에 유형을 명시적으로 할당할 수도 있다. 이 네임스페이스에는 인스턴스 문서에서만 사용할 수 있는 약간의 속성만 포함되어 있다. 이 type 속성을 사용하는 것은 일부 프로그래밍 언어에서의 타입 강제변형(type casting)과 유사하다. 다음의 예는 AutorId 유형에 genericId 요소(스키마에서는 정의되지 않음)를 명시적으로 할당한 것이다.

Notice that AuthorId is the same type that we assigned to the global authorId attribute shown above. This illustrates that you can assign simple types to either attributes or text-only elements to constrain their values respectively. Also, it's important to note that the xsi:type technique for assigning type only applies to elements and not attributes.

여기에서 주목할 것은 AuthorId가 위에서 global 속성 authorID에 할당한 것과 동일한 유형이라는 것이다. 이와같이 simple 유형을 속성이나 문자만 가능한 요소에 지정하여, 그들의 값을 제한할 수 있다. 단, 유형을 지정할 때 xsi:type 기법을 사용하는 것은 요소에만 가능하고 속성에는 불가능하다는 점을 기억해야 한다.

Simple 유형 정의하기

대부분의 프로그래밍 언어는 여러가지 내장유형을 구조형으로 재배치하는 것만 허용할 뿐, 값 공간을 사용자가 정의할 수 있는 새로운 simple 유형을 정의하는 것은 안된다. 이러한 점에서 XML Schema는 차이가 있다. XML Schema의 경우 사용자가 맞춤형 simple 유형을 정의할 수 있다. 이때 사용자 simple 유형의 값 공간은 기반이 되는 내장 유형의 값공간의 부분집합이어야 한다.

새로운 simple 유형은 xsd:simpleType 요소를 사용하여 정의할 수 있다. xsd:simpleType 요소내에서 (xsd:restriction 요소를 사용하여) 값 공간을 제한하고자 하는 기본 유형을 정의한다.  xsd:restriction 요소에서는 기본 유형으로부터 제한할 내용을 지정한다. 예를 들어 다음의 simple 유형은 xsd:double 과 xsd:date 값공간을 xsd:minInclusive와 xsdmaxInclusive 요소를 사용하여) 좀더 구체적인 범위로 줄이고 있다.

다음 문서에는 위에서 정의한 요소의 유효 인스턴스가 포함되어 있다.

XML Schema는 이러한 유형에 사용할 수 있는 facet을 정의하고 있다.(그림 1) 대부분의 facet은 모든 유형에 적용되지 않는다. (특정 유형에만 의미를 갖는다.)  대부분의 facet은 유형의 값 공간을 제한하지만, patter facet은 해당 유형의 사전공간(lexical space)을 제한한다. 값공간이나 사전공간을 제한하면 간접적으로 상대방도 제한하게 된다. (값공간을 제한하면 사전공간에 영향을 미치게 된다는 뜻) 위의 예에서는 기본 유형의 값 공간을 제한하고 있는데, 아래의 예에서는 regular expression을 사용하여 문자열의 사전공간을 제한한다.

다음 문서는 이렇게 정의된 요소들에 대한 적법한 인스턴스가 포함되어 있다.

regular expression(pattern facet으로 지정된)에 맞는 문자열만 해당 유형의 유효 인스턴스로 간주된다.

<표 1> Facets

또다른 재미있는 facet으로는 xsd:enumeration이 있다. 이는 값공간을 나열된 값(enumerated values)로 제한하는 것이다. 다음은 xsd:NMTOKEN의 값공간을 4개의 지정된 나열값으로 제한하는 예이다.

아래 문서는 위에서 정의한 요소에 대한 유효 인스턴스를 담고 있다.

<표 2> Simple 유형 구축 기법

유형의 값 공간을 제한하는 외에, 다른 유형의 list 또는 union인 새로운 simple 유형을 만들 수도 있다. xsd:restriction 대신 xsd:list 또는 xsd:union 요소를 사용하면 된다. (표 2 참조) xsd:list를 사용할 때 지정된 값공간으로부터 공백문자로 구분된 값 목록을 정의한다. 명심할 것은 xsd:list 또는 xsd:union을 사용할 때에는 xsd:restriction 과 같은 derivation hierarchy가 없기 때문에, 이 경우에는 유형 호환성이 성립되지 않는다는 것이다. 아래는 SSN 값의 목록으로서 AuthorList라는 새로운 유형을 정의하는 예이다.

다음 문서는 authors의 유효한 인스턴스를 담고 있다.

xsd:union의 경우, 여러개의 값 공간을 합한 새로운 값 공간의 새로운 유형을 생성할 수 있다. union 유형의 인스턴스는 지정된 값공간 중 어떤 하나로부터의 값을 가질 수 있다. 예를 들어, 다음의 AuthorId 유형은 SSN 값공간과 PublisherAssignedId 값공간을 결합하였다.

다음 두가지는 모두 authorId 요소에 대한 유효한 인스턴스이다.

XML Schema는 사용자정의 유형을 지원한다. 좀더 정확하게 말하자면 맞춤형 값/사전 공간을 지원한다. 이것이 XML의 강력한 기능중 하나이다. 대부분의 프로그래밍 언어는 이러한 기능을 허용하지 않으므로, 개발자들은 이러한 문제를 응용프로그램 코드 (일반적으로 property setter를 사용하여) 처리해야한다. 정확한 필요에 따라 맞춤형 값/사전 공간을 정의하는 능력이 있음으로써 오류 처리와 검증코드를 레이어 수준에서 처리가 가능하다.

Complex 유형 정의

XML Schema는 여러가지 simple 유형(이나 값 공간)을 배열하여 complex 유형이라고 하는 구조로 만들 수 있다. 새로운 complex 유형을 정의하려면 아래의 예와 같이 스키마의 target 네임스페이스내에서 xsd:complexType 요소를 사용하면 된다.

xsd:complexType 요소는 compositor라는 것이 포함되어 있는데, 그것은 그 유형의 내용의 구성, 즉 콘텐트 모델을 서술한다. XML Schema는 3개의 compositor를 정의한다. 이들은 xsd:sequence, xsd:choice, xsd:all 을 포함한 complex 유형 정의에 사용될 수 있다.

Compositor 는 particle를 포함한다. particle은 다른 compositor, 요소 선언, wildcard, 모델 그룹 등을 포함한다. 속성 선언은 particle로 간주되지 않는다. 반복이 없기 때문이다. 따라서 속성 선언은 compositor 내에 위치하지 않고 complex type 선언 끝에 있는 compositor 이후에 위치한다.

<표 3> Complex 유형 Compositor

An element declaration (xsd:element) is probably the most commonly used particle. The following complexType named AuthorType defines an ordered sequence of two element children and an attribute, each of a different simple type:

요소선언(xsd:element)는 가장 널리 사용되는 particle이다. 아래의 AuthrType 이라는 compelxType은 2개의 요소의 순서있는 sequence와 하나의 속성으로 구성된다. 각각은 simple 유형이다.

xsd:complexType 요소내에 선언된 요소와 속성은 로컬로 간주된다. 로컬 요소와 속성은 정의된 해당 문맥 내에서만 사용될 수 있다. 이는 로컬 요소/속성이 인스턴스 문서에서 네임스페이스 정규화(qualified)가 필요한지에 관한 흥미로운 질문을 불러온다. 로컬 요소와 속성은 항상 target 네임스페이스로 정규화된 부모 요소(대부분 글로벌)내에 포함되므로, 정규화가 필요하지 않다고 주장할 수 있다. 이는 대부분의 프로그래밍 언어의 작동방식과 유사하다. 클래스를 네임스페이스 내에 선언하면, 클래스 이름만이 네임스페이스에 의해 정규화(qualified)되고, 로컬 멤버는 정규화되지 않는다. 

이러한 이유로 XML Schema에서 로컬 요소와 속성은 정규화하지 않는 것이 기본이다. 따라서, autho 요소의 적합한 인스턴스는 다음과 같은 형태를 갖는다.

하지만 XML Schema에서는 로컬 요소/속성을 정규화할지 말지를 제어하는 방법이 있다. 아래 예와 같이 xsd:element/xsd:attribute 에 form 속성을 사용하거나, xsd:schema 에elementFormDefault/attributeFormDefault 를 사용하면 된다.

이 스키마에 대해, 다음의 인스턴스는 유효한 인스턴스가 된다. (위에 있는 인스턴스는 유효하지 않다)

대부분의 경우 스키마에 부합하기만 하면, 어떠한 네임스페이스 스타일을 사용하던 무방하다.

아울러 아래와 같이,  글로벌로 선언된 요소/속성을 complex 유형내에서 ref 속성을 사용하여 참조하는 방법도 가능하다.

id와 name이 글로벌 요소이므로, 인스턴스 문서에서 정규화하여 사용해야 한다. "ref"를 사용하면 AuthorType 문맥 내에서 글로벌 요소를 사용할 수 있지만, 정규화 필요성은 변하지 않는다. phone 요소는 로컬로 정이되어 있으므로, form 을 어떻게 사용하느냐에 따라 정규화시켜야 할수도, 아닐 수도 있다. xsd:schema에서 elementFormDefault="unqualified"를 사용했다고 가정하면, 유효한 인스턴스는 아래와 같은 형태를 취한다.

아래는 중첩된 complex 유형, 다른 compositer, 반복 particle을 사용하는 좀더 복잡한 예이다.

이 예에서 AuthorType는 sequence와 속성으로 구성되는데, sequence 내에는 또다른 compositor인 choice와 3개의 요소가 포함된다. 이들 요소중 일부는 다른 사용자 정의 complex 유형인 AddressType 과 PublicationListType) 이기 때문에, 효과적으로 중첩된 구조를 정의하고 있다. choice란 "name" 또는 "fullName"요소 중 하나만 허용된다는 뜻이다. 마지막으로 AddressType에 있는 all 은 순서는 관계없다는 의미이다.

또한, phone 요소 선언은 minOccurs/maxOccurs 속성을 사용하여 횟수를 제한하고 있다. 횟수 제한은 complex 유형에 들어 있는 모든 particle에 적용할 수 있다. 기본 값은 1로서, 해당 particle이 지정된 위치에 정확하게 한번 등장해야 함을 의미한다. minOccurs="0"을 지정하면 해당 particle이 옵션이라는 뜻이며, maxOccurs="unbounded"는 particle이 얼마든지 반복될 수 있음을 의미한다. 아울러 minOccurs="3" 이나 maxOccurs="77"과 같이 임의의 한계를 설정할 수도 있다. occurence 제한을 compositor에 사용하면 해당 그룹 전체에 적용된다. (PublicationListType의 경우, choice에 횟수 제한을 적용하였다.) 아래는 새로운 AuthorType에 대한 유효한 인스턴스의 예이다.

기본으로 complex 유형은 폐쇄된(closed) 콘텐츠 모델이다. 이는 지정된 particle만이 인스턴스내에 나타나야 함을 의미한다. 하지만, XML Schema는 wildcard라는 것을 사용하여 개방형(open) 콘텐츠모델을 정의할 수 있다. complex 유형 내에 xsd:any를 사용하면, 해당 위치에 어떠한 요소도 들어갈 수 있음을 의미하여, 미리 예상할 수 없는 것에 대한 placeholder로 만들수 있다. 아울러 xsd:anyAttribute 를 사용하면 속성에 대한 placeholder도 정의할 수 있다.

아래는 위에서 정의한 author 요소에 대한 유효한 인스턴스의 예이다.

When using wildcards it's also possible to constrain the namespace the content actually comes from. Both xsd:any and xsd:anyAttribute come with an optional namespace attribute that may contain any of the values shown in Table 4. This makes it possible to be very specific about where the wildcard replacement content comes from. 

wildcard를 사용할 때, 내용이 올 네임스페이스를 한정하는 것도 가능하다. xsd:any와 xsd:anyAttribute 모두 옵션으로 네임스페이스 속성을 넣을 수 있는데, 표 4에 있는 값중 하나를 넣을 수 있다. 이렇게 하면, wildcard 내용을 한정할 수 있다.

<표 4> Wildcard 네임스페이스 속성

wildcard를 사용할 경우, 스키마 프로세서가 검증과정에서 그 wildcard 내용을 어떻게 처리해야 하는지를 지정할 수 있다. xsd:any와 xsd:anyAttribute는 모두 processContents 속성이 있는데, lax/strict/skip 등 세가지 중 하나의 값을 가질 수 있다. 이값은 wildcard 위치에 들어오는 내용에 스키마 검증을 어떻게 수행해야 하는지를 나타낸다. Strict란 내용에 대해 반드시 검증해야 한다는 뜻이다. Lax는 schema 정보가 있을 경우에만 검증을 해야 함을 의미하고, skip은 schema 검증을 수행하지 말라는 의미이다.

 Let's look at an example that uses these attributes. The schema for SOAP 1.1 actually leverages wildcards and both of these attributes to define the structure of the soap:Header and soap:Body elements:

이들 속성을 사용하는 예를 살펴보자. SOAP 1.1 스키마는 실제로 wildcard를 활용하고 있으며, 이들 속성들을 soap:Header와 soap:Body 요소의 구조를 정의하고 있다.

스키마에 따르면, soap:Header는 0개 이상의 요소를 포함할 수 있고, 속성도 갯수제한없이 포함시킬 수 있다. 요소나 속성 모두 targetNamespace가 아닌 네임스페이스에 속해야 한다. 반면 soap:Body의 경우 0개 이상의 요소와 갯수 제한없는 속성을 포함시킬 수 있는데, 네임스페이스는 어디라도 관계없다. 이 두가지 경우에서 ㄱ검증은 스키마 정보가 런타임으로 제공될 경우에만 수행된다. (lax) soap:Header 또는 soap:Body에 어떠한 내용이 들어올 지 예측할 수 있는 방법이 전혀 없기 때문에, wildcard는 유연하고도 개행된 프레임워크를 정의하는 방법을 제공한다.

스키마 찾기 및 관리

이 쯤에서 발생할 질문중의 하나는 XML Schema 프로세서가 주어진 인스턴스 문서에 대한 스키마 정의를 어떻게 실행중에 알아내는 방법이다. XML Schema 프로세서는 인스턴스 문서의 네임스페이스를 키로 해당하는 스키마를 찾아내지만, XML Schema 사양에는 정확히 어떻게 처리할지에 대해서는 정의되어 있지 않다. 대부분의 프로세서는 필요한 모든 스키마를 미리 스키마 캐시에 불러 올 수 있도록 허용한다. 그런 뒤 실행중에는 프로세서에게 스키마 캐시만 지정하면 특정 인스턴스에 필요한 스키마를 효과적으로 참조할 수 있다.

XML 스키마는 인스턴스문서에서 스키마 위치를 제공하는 방법도 정의하고 있다. 이는 아래와 같이 xsi:schemaLocation을 사용하면 된다.

xsi:schemaLocation 속성은 네임스페이스명 목록과 URI 위치 쌍을 공백문제로 분리하여 제공할 수 있다. 이를 사용해 특정 스키마 파일을 찾아낼 수 있다. 하지만, 이것은 힌트에 불과할 뿐, 프로세서가 더 효과적인 메커니즘이 있을 경우, 다른 곳을 찾을 수도 있다.

결론

XML 스키마는 XML을 위한 표현력 짱 유형시스템을 제공하여, 아주 강력한 서비스를 제공할 수 있다. 이 글에서는 simple유형 및 complex 유형 정의를 포함한 기본적인 XML 스키마 정의에 대해 다루었다. Simple 유형 정의를 사용하면, 문자만이 가능한 유형 및 속성에 맞춤형 값공간을 정의할 수 있다. Complex 유형 정의를 사용하면 Simple 유형을 배열하여 구조체를 만들 수 있다.

XML Schema는 실제로 여기에서 논의한 것보다 훨씬 더 많은 기능이 있다. 예를 들어 complex 유형 정의는 기존의 유형을 확장하거나 제한하는 등의 유도 유형을 만들 수 있어, 객체지향의 클래스 상속성과 비슷한 방법으로 complex 유형의 계층화를 정의할 수 있다. Complex 유형 계층화를 사용하면, 인스턴스 문서에서 대체 기법도 가능하다. XML Schema는 또한 XML Schema 정의를 여러개의 파일과 네임스페이스로 분리한 후, 나중에 포함(include) 또는 수입(import)하는 방법을 통해 재사용성, 편의성 및 유지관리성이 증가시킬 수 있다. 이러한 고급 주제는 다음 글을 위해 남겨둔다.

XML Schema에 관한 좀더 자세한 내용은 Essential XML Quick Reference를 참고하라. XML Schema 챕터에는 각각의 구조와 데이터유형에 관한 간단한 설명과 예제가 포함되어 있다.

.===

원문 : https://msdn.microsoft.com/en-us/library/aa468557.aspx

모든 XML 기술중에서 XML Schema는 소프트웨어 개발자에게 가장 중요하다. XML 문서에 유형(type) 정보를 넣을 수 있게 되었기 때문이다.

먼저, XML Schema 이전 상황부터 살펴보자. XML 1.0 사양은 XML 어휘를 서술하는 내장 문법인 DTD(Document Type Definitions) 와 함께 출현했다. XML 1.0 이 그 전신인 SGML (Standard Generalized Markup Language)의 문법을 물려받은 것을 고려할 때, DTD는 사실 상당한 기간을 살아남았다고 할 수 있다.

DTD를 사용하면 XML 문서의 구조를 서술할 수 있다. 예를 들어, 직원 정보를 서술하기 위해 다음과 같은 XML 어휘를 사용한다고 해보자.

다음은 이 문서의 구조를 서술하는 DTD 이다.

이 DTD는 DOCTYPE 선언을 통해 원래의 문서에 연결할 수 있다. 아래는 그 예이다.

DTD를 사용하는 가장 큰 장점은 검증이다. 검증을 할 때, XML 1.0 파서는 이 XML 1.0 파일을 읽어들이면서 연계된 DTD도 함께 읽어들여, 정의에 합당한지 검증한다. DTD를 사용하여 검증을 하게 되면, 어플리케이션에서 다루어야할 많은 상당한 양의 오류 처리를 감소시킬 수 있다.

DTD가 많은 SGML 기반의 전자출판 응용에는 잘 어울리지만, 현재의 Web 환경과 같은 소프트웨어 개발 분야에 적용하면서 DTD의 한계는 금방 드러나게 되었다. DTD의 주요한 한계로는 DTD 문법이 XML 기반이 아니며, 네임스페이스를 지원하지 않고, 전형적인 프로그래밍 언어의 데이터타입을 지원하지 않으며, 맞춤형 유형을 정의할 수 없다는 것 등이다.

DTD 문법 자체가 XML이 아니기 때문에, 프로그램적으로 정의를 처리할 때, 표준 XML 도구들을 사용할 수 없다. 대부분의 XML 1.0 프로세서는 DTD 검증을 지원하기는 하나, DTD 문법의 복잡성으로 인해 DTD에 있는 정보에 대한 프로그램적 접근을 지원하지 않는다.

DTD는 XML 네임스페이스가 존재하기 전에 만들어졌으므로, 두가지가 함께 잘 작동하지 않는다는 건 놀라운 일이 아니다. 사실 DTD를 사용하여 네임스페이스를 지원하는 문서를 만든다는 것은 동그란 구멍에 네모난 통을 끼우려는 것과 비슷하다. 이 작업의 끔찍한 일면을 알고싶다면, 내가 네임스페이스 지원 DTD를 제공하는 XML Files 컬럼을 쓴 2001년 5월 작업을 확인하기 바란다. 결론적으로, 대부분의 개발자들은 DTD나 네임스페이스 둘중의 하나만 사용하였고, 둘 다 사용하는 경우는 거의 없었다.

DTD는 프로그램 데이터 유형이 존재하지 않는 문서 중심 시스템을 위해 개발되었다. 그 결과 속성을 기술하는 단 몇가지의 유형 식별자만이 존재한다. (그림 1 참고) 이러한 유형식별자도 일반적인 프로그램 언어에서 사용하는 유형과 전혀 다르다. 이 식별자들은 텍스트(CDATA)의 특별한 케이스에 불과하다. 아울러 이러한 유형은 텍스트만 있는 요소에는 적용할 수 없고 속성에만 적용할 수 있다.

<그림 1> DTD 유형의 종류

마지막으로 DTD 유형 시스템은 확장이 불가능하다. 즉, 그림 1에 있는 유형만 쓸수 있다는 것이다. 자신의 문제 영역에서 의미있는 맞춤형 유형을 생성하는 것은 DTD로는 불가능하다. 이러한 한계만으로도 XML Schema가 새롭고도 흥미로운 미래를 제안하자 XML 개발자는 DTD로부터 탈출할 충분한 이유가 되었다.

XML Schema 기본

XML Schema는 그 자체가 XML 어휘를 사용하여 XML 인스턴스 문서를 기술한다. "인스턴스(instance)"라는 용어는 스키마가 여러 문서의 클래스를 서술하고, 여러 개의 다른 인스턴스가 존재할 수 있기 때문이다. (그림 2) 이것은 오늘날 객체지형 시스템에서 클래스와 객체와의 관계와 비슷하다. 클래스는 스키마에 해당하고, 객체는 XML 문서에 해당한다. 따라서 XML Schema를 사용하는 동안 하나 이상의 문서와 작업을 하게 된다.

<그림 2> 네임스페이스 식별자 링크

스키마 정의에 사용되는 요소는 http://www.w3.org/2001/XMLSchema 네임스페이스에 들어 있다. 나는 이 문서에서 이 네임스페이스를 xsd로 결합할 것이다. 다음은 기본 스키마 템플릿이다.

스키마 정의에는 반드시 최상위 요소인 xsd:schema가 있어야 한다. xsd:schema 내에는 다양한 요소들이 중첩될 수 있는데, xsd:element, xsd:attribute, xsd:complexType 등이 그 예이다. 

스키마 정의 자체가 XML 문서이므로 DTD의 한계 중에서 첫번째 한계가 해결된다. 스키마 정의도 표준적인 XML 1.0 도구 및 서비스(예: DOM, SAX, XPath, XSLT 등)를 사용하여 처리할 수 있다. 이와 같은 간편성으로 인해 스키마 도구가 홍수처럼 쏟아져 나오게 되었다.

XML Schema 와 네임스페이스

xsd:schema 요소 내에 위치한 정의는 targetNamespace 속성에 정의된 네임스페이스로 자동적으로 연결된다. 위의 예의 경우, 스키마 정의는 http://example.org/employee 네임스페이스에 연계된다.

네임스페이스 식별자는 XML 문서와 해당 Schema 정의를 연결하는 키이다. (그림 2 참고) 예를 들어, 다음의 XML 인스턴스 문서는 http://example.org/employee/ 네임스페이스에서 온 employee 요소를 포함한다.

employee 요소의 네임스페이스는 스키마 정의의 targetNamespace와 동일하다.

employee 요소를 처리하면서 스키마의 장점을 활용하려면, 처리기가 올바른 스키마 정의를 찾을 필요가 있다. 스키마 처리기가 특정 네임스페이스를 위한 스키마 정의 파일을 찾는 방법은 사양에 정의되어 있지 않다. 그러나 대부분의 처리기는 스키마를 메모리 캐시에 불러들인 후, 문서 처리에 사용하는 것을 허용한다. 예를 들어 아래의 JScript® 기반 코드은 MSXML 4.0을 사용한 간단한 방법을 나타낸 것이다.

Microsoft® .NET 이나 기타 대부분의 XML Schema 처리기도 이와 비슷한 방법으로 작동한다.

아래(역자 주 : XML0204.exe 인데 링크가 깨져서 파일은 없음)는 명령어 방식의 검증 유틸리티로서, 이 글에 논의된 원칙들을 시험해 볼 수 있다. 이 검증 유틸리티에서는 검증하고자 하는 인스턴스 문서와 함께, 필요에 따라 많은 스키마 정의 파일을 지정할 수 있다. 명렁어 사용법은 다음과 같다.

XML Schema는 아울러 schemaLocation 속성을 사용하여, 인스턴스 문서내에서 필요한 스키마 정의문서의 소재를 제공할 수도 있다. schemaLocation속성은 http://www.w3.org/2001/XMLSchema-instance 네임스페이스에 있으며, 이 네임스페이스는 인스턴스 문서에서만 사용되는 속성만 특별히 담고 있다. 나는 지금부터 이 네임스페이스를 xsi 접두사와 결합시켜 사용하겠다. xsi:schemaLocation 속성은 아래의 예와 같이 공백문자로 구분된 네임스페이스 식별자와 URL의 쌍으로 이루어진다.

이 경우, 처리기가 http://example.org/employee/ 네임스페이스를 위한 적절한 스키마 정의에 이미 접근하지 못했을 경우, http://develop.com/aarons/employee.xsd 로부터 다운로드 받을 수 있다.

요소와 속성(Elements and Attributes)

요소와 속성은 targetNamespace의 일부로서 정의될 수 있다. 각각 xsd:element와 xsd:attribute 요소를 사용한다. 예를 들어 아래와 같은 인스턴스 문서를 기술하려고 한다고 하자.

가장 간단한 방법은 다음과 같은 스키마 정의를 사용하면 된다.  

주목할 점은 xsd:element와 xsd:attribute 선언을 xsd:schema 요소에 넣기만 함으로써, 자동적으로 이들이 http://example.org/employee/ 네임스페이스에 연결되었다는 것이다. 이러한 선언은 스키마에서 global 로 간주된다. 이들이 최상위 xsd:schema 요소의 자식요소(child)이기 때문이다.

이 스키마에서는 이들 요소/속성이 http://example.org/employee/ 네임스페이스의 일부라고 지정하였기 때문에, (위에서 보인 원래의 인스턴스처럼) 인스턴스 문서에서 해당 네임스페이스에 연결시켜야 한다. 인스턴스에 네임스페이스를 미세하게 변경해도 인스턴스가 무효가 된다. 예를 들어, 다음의 문서는 무자격(unqualified) name, hiredate, salary 요소 그리고 무자격 id 속성이 포함되어 있다.

위의 스키마 정의에서는 이들 요소/속성이 http://example.org/employee/ 네임스페이스에 속한다고 했지만, 여기에서는 이들 요소/속성이 네임스페이스에 연결되어 있지 않아 이 인스턴스가 무효가 된 것이다.

이번엔 훨씬 더 미세한 변화로서, 네임스페이스 접두사 대신 기본 네임스페이스 선언을 사용하는 경우를 살펴보자.

이 경우 모든 요소들은 기본 네임스페이스(http://example.org/employee/)에 연결되었지만, id 속성만은 여전히 무자격이다. 기본 네임스페이스는 속성에는 적용되지 않기 때문이다. 그 결과 이 문서 인스턴스도 무효로 간주된다.

보시는 바와 같이, XML 네임스페이스는 XML Schema의 가장 핵심에 있다. XML Schema를 사용하려면 네임스페이스의 작동방법에 대해 완전히 이해해야 한다. 인스턴스 문서가 스키마에 지정된 것과 일치하지 못하면 무효화되기 때문이다.

아울러 이 간단한 예제에는 요소의 내용 및 네임스페이스 내의 요소간의 구조적 관계등에 아무런 제한도 없다는 것도 알 수 있다. 이 스키마는 아래의 DTD와 동등하다. (단 속성 선언은 생략)

따라서 다음의 XML 인스턴스 문서가는 전혀 이치에 닿지 않지만, 스키마에는 적합하다.

XML Schema는 Complex 유형 선언을 통해 요소의 구조를 기술할 수 있다.

Complex 유형 선언 

DTD를 사용할 경우, 요소의 내용 모델은 다음과 같이 ELEMENT 선언에서 정의할 수 있다.

이 ELEMENT 선언은 employee 요소에 name 요소, hiredate 요소, salary 요소 순으로 들어 있음을 말하고 있다.

XML Schema에서는 xsd:complexType 요소와 xsd:element 선언을 중첩시킴으로써 요소의 내용 모델을 정의할 수 있다. 다음은 그 예이다.

XML Schema 모델은 변수에 유형선언을 결합한다는 의미에서 좀더 프로그래밍 언어와 비슷하다. xsd:complexType을 사용하면 어떤 구조를 가진 요소의 유형을 선언할 수 있다.  요소 선언 내에 xsd:complexType 을 중첩시키면 요소(변수와 같이)에 효과적으로 결합시킬 수 있다. 유형선언이 DTD로부터 XML Schema로의 중요한 패러다임 이동이다.

xsd:complexType 요소의 내부에 넣는 것은 DTD ELEMENT 선언 다음 괄호 안에 무엇을 넣는 것과 유사하다. 위에 있는 employee ELEMENT 선언은 name, hiredate, salary 요소의 순서있는 나열을 정의한다. 콤마 대신 pipe(|) 를 사용하면 하나의 요소를 선택한다는 의미이다.

XML Schema에서는 compositor 요소를 통하여 내용모델의 특성을 정의할 수 있다. compositor는 xsd:complexType 요소의 자식요소로 중첩시켜 사용한다. XML Schema는 xsd:sequence, xsd:choice, xsd:all 등 세가지 compositor가 있다.

<그림 3> Complex 유형의 Compositor

xsd:sequence와 xsd:choice 요소는 위에서 설명한 DTD 예제들과 동등하다. 하지만, xsd:all은 새로운 개념으로서, 순서에 관계없이 모든 아이템으로 구성되는 내용모델을 지정한다. 이는 DTD 문법에 정의되어 있지않다. 구지 DTD를 이용하여 이와 같은 의미론을 정의하려면 아래와 같이 모든 요소를 명시적으로 나열하면 된다.

<!ELEMENT employee ( (name, hiredate, salary) |
                               (name, salary, hiredate) |
                               (hiredate, name, salary) |
                               (hiredate, salary, name) |
                               (salary, name, hiredate) | 
                               (salary, hiredate, name) ) >

이와 같이, 순열과 조합으로 인해 짜증이 나기 시작할 것이다. XML Schema는 "all" compositor도 sequcen와 choice처럼 1급 compositor이기 때문에 훨씬 깔끔하다. 

Compositor 요소는 글로벌 요소선언, 로컬 요소 선언, 다른 compositor, 기타 와일드카드나 group 참조와 같은 기타 구조요소에 대한 참조를 포함할 수 있다. 그림 4에 표시한 예제 스키마는 xsd:complexType에서 다른 부분에 정의된 글로벌 요소를 참조하는 예이다.

<그림 4> 글로벌 요소 참조의 예

이상에서 알 수 있는 것과 같이 ref 속성은 접두사가 있는 요소명을 취한다. 스키마에서 글로벌 요소를 선언하면, 이는 자동적으로 targetNamespace로 연계된다는 것을 기억하라. 글로벌요소를 이름으로 참조하면, 이들은 정규화 이름으로 취급된다. 만약 ref="tns:name" 대신 ref="name"을 사용한다면, 스키마 처리기는 아무런 네임스페이스에도 속하지 않는 name 요소 혹은 기본 네임스페이스에 있는 name 요소를 찾게 된다. 하지만 이 경우, name요소는 http://example.org/employee 네임스페이스에 속해 있으므로, 찾을 수 없게되고, 유효하지 못한 XML 문서가 된다.

http://example.org/employee/ 네임스페이스를 어떤 문서의 기본 네임스페이스로 지정할 경우, 그림 5와 같이 접두사를 사용하지 않고도 글로벌 요소를 참조할 수 있다. (즉, ref="name"이 적법)

<그림 5> 네임스페이스 접두사를 사용하지 않는 방법

그림 4와 그림 5의 스키마 샘플은 논리적으로 동등하다. 직렬화 형태가 다를 뿐이다. 두가지 모두 employee요소의 내용을 제한하고 있다. employee 요소는 name, hiredate, salary요소를 반드시 포함해야 하고, 이들 모두 http://example.org/employee/ 네임스페이와 연결되어 있어야 한다.

로컬요소 선언

인스턴스 문서에서 사용할 유일한 top-level 요소는 employee이므로 name, hiredate, salary를 글로벌 요소로 선언할 이유는 전혀 없다. 따라서 name, hiredate, salary요소를 employee 요소의 내용 모델 내에서 로컬로 선언할 수 있다.

예를 들어 그림 6에 있는 스키마에는 로컬 요소의 시퀀스를 포함하는 employee 요소 선언이 포함되어 있다. 이 예에서 name, hiredate, salary요소는 실제 employee요소의 일부로 선언되어 있어 이 인스턴스의 다른 곳에서는 사용할 수 없다. employee 요소 선언은 최상위 xsd:schema 요소의 자손으로 글로벌하게 나타나는 오직 하나의 요소이다. 이것은 재미있는 질문을 유도한다. 로컬요소는 targetNamespace에 연결되어 있는 것인가?

<그림 6> 로컬 요소 선언

로컬 스콥과 네임스페이스

이 질문에 대한 해답을 이해하기 쉽도록 C#과 같이 네임스페이스를 지원하는 프로그래밍 언어의 간단한 예를 생각해 보자. 아래의 C# 클래스 선언은 "example" 네임스페이스 내에 정의되어 있다.  

이 네임스페이스에서 어떤 식별자가 실제로 보일 것인가? 단하나! employee 뿐이다. name, hiredate, salary 식별자는 employee 클래스 내에서만 보인다. 따라서, 아래에서 보는 바와 같이 employee는 네임스페이스 식별자를 붙여 정규화(qualified)해야 하지만, name 등의 로컬 멤버는 불가능하다.

XML 스키마 설계자는 로컬 스콥의 적용에 대해 고려한 것처럼 보인다. 기본적으로 이와 동일하게 작동되기 때문이다. XML Schema에서도 인스턴스 문서에서 글로벌 요소만 정규화(qualified) 시켜야 하며, 로컬 요소는 unqualified하게 남겨두어야 한다. 아래는 그림 6에서 보인 스키마의 유효한 인스턴스 문서의 예이다.

이 인스턴스를 변경하여 name, hiredate, salary요소를 http://example.org/employee 네임스페이스에 정규화시킬 경우, 스키마에 맞지 않게 된다. 기본 네임스페이스 선언을 아주 미묘하게만 변화시켜도 이런 일이 발생함을 기억해야 한다.

이러한 방식을 모두다 좋아하는 건 아니기 때문에 XML Schema 설계자는 로컬 요소를 인스턴스에서 정규화(qualified)시킬 것인지 말것인지를 제어할 수 있도록 만들었다. 아래와 같이 form 속성을 사용하여 요소별로 제어하면 된다.

이 employee 요소에 대한 적합한 인스턴스는 아래와 같이 자식요소로서 정규화 name 요소, 비정규화 hiredate 요소, 정규화 salary 요소가 순서대로 나와야 한다.

또, 아래와 같이 elementFormDefault 속성을 사용하면 스키마에 있는 모든 로컬요소 선언의 기본 설정을 뒤집을(toggle) 수 있다.

이렇게 하면 기본으로 인스턴스에서 모든 로컬 요소를 정규화(qualified)시켜야 한다. (특정한 요소에 대해 form 속성으로 설정을 엎어쓰지 않았다는 가정하에), 다음은 그 예이다.

이 경우 모든 요소가 정규화요소이므로, 기본 네임스페이스 선언을 사용할 수 있고, 다음 인스턴스가 유효하게 된다.

횟수 제한(Occurrence Constraints)

DTD에서는 *. +. ? 등의 변경자(modifier)를 사용하여 내용모델에서 요소의 등장횟수를 제어할 수 있다. XML Schema는 이러한 변경자를 사용하지 않고 단순히 minOccrs와 maxOccurs 등 두가지 속성을 정의한다. 이 속성들은 요소 선언, compositor, 기타 몇가지 스키마 구조에서 사용될 수 있다.

아이템이 등장할 최소횟수와 최대횟수는 각각 minOccurs와 maxOccurs를 사용하여 지정한다. 이 속성의 기본값은 모두 1이다. maxOccurs의 값으로 "unbounded"를 사용하면 등장회수를 제한하지 않는다는 뜻이다.

다음의 DTD ELEMENT 선언을 살펴보자:

이 ELEMENT 선언은 그림 7과 같이 minOccurs/maxOccurs과 여러개의 중첩된 compositor를 사용하여 XML Schema로 다시 작성할 수 있다.

<그림 7> minOccurs/maxOccurs 사용 예