IT/모바일
저자: 스콧 민즈(W. Scott Means), XML in a Nutshell의 공동 저자
장기적인 관점에서 봤을 때, 문서 형식을 XML로 바꾸어야 한다는 것은 이미 결론이 났지만, 아직 첨예한 문제 한 가지가 남아 있다. 이전의 문서는 어떻게 할 것인가이다. 옛 문서를 모두 저장해 놓고, 새로운 문서 작성에만 매달리면 아주 편하겠지만, IT 업계에서 모토로 삼고 있는 것은 급진적인 개혁이 아니라, 점진적인 발전이다. 그래서 옛 문서를 XML 형식으로 바꾸는 문제는 앞으로의 과제이다.
불행하게도 워드 프로세서 문서부터 스프레드 시트, 웹 페이지, 텍스트 파일에 이르기까지 비구조적인 문서는 너무 많다. 여기에 XML로의 변환 과정을 좀더 쉽게 할 수 있는 몇 가지 기술을 소개한다.
실제 예: 기상 예보
인터넷의 가장 큰 장점은 양질의 광대한 정보에 무료로 접근할 수 있다는 것이다. 미 정부 사이트도 이러한 무료 정보의 출처로 중요한 위치를 점하고 있다. National Weather Service에서는 기상 예보와 관측을 한다. 이러한 정보는 비행기 조종사가 비행할 때, 연방항공국(Federal Aviation Administration) 캐스터가 알려 주는 것과 동일하다. (자세히 알고 싶으면, METAR 보고서를 읽기 바란다.)
[편집자 주: METAR는 Aviation Routine Weather Report의 머릿글자를 따서 만든 말로, 불어에서 왔다.]
일례로 다음 URL에서는 컬럼비아 메트로폴리탄 공항(Columbia Metropolitan Airport)부근의 현재 기상 관측 사항을 다운로드할 수 있다.
ftp://tgftp.nws.noaa.gov/data/observations/metar/decoded/KCAE.TXT
매 시간 업데이트되긴 하지만, 우선은 이 정보로 작업을 해 보자:
[편집자 주: 첫째 행과 10번째 행은 문장의 길이가 길어서 다음 문장으로 넘어 갔다. 이 글에서는 이처럼 문장이 길어질 때 다음 문장의 첫 단어를 모두 들여쓰기할 것이다.]
소스 문서가 있으니, 이제 XML로 변환하자.
원자 엘리먼트 분리
실수로 물리학 입문 기사가 끼어 든 것은 아니니, 오해 없기 바란다. XML 문서는 엘리먼트로 구성되어 있어서 소스 문서를 변환하려면 어떤 구조로 되어 있는지 먼저 파악해야 한다.. 문서 정보에서 눈으로 볼 수 없는 가장 작은 조각이 XML 문서의 엘리먼트이다.
첫째 행부터 하나하나 살펴보도록 하자.
드러나 있지는 않지만, 둘째 행의 코드는 관측 당시의 날짜와 시간을 나타내는 것이 분명하다. 이 행에서 눈 여겨 볼 것은 시간이 현지 시간과 협정 세계 표준시(UTC)의 두 가지 방식으로 표현되어 있다.
스콧 민즈는 oreilly.com에서 What"s New in the DOM Level 2 Core? (한빛 사이트: DOM Level 2 Core의 새로운 특성은 무엇인가?)라는 XML 관련 기사도 쓴 바 있다. DOM Level 2는 2000년 11월 공식적인 W3C의 권고안이 되었다. 이 기사에서는 DOM(Document Object Model)을 소개하며, DOM 개발자에게 새로운 Level 2의 특성을 안내해 준다.
컨텐츠에서 프리젠테이션 분리
일반적으로 문서에서 가독성과 미학적인 측면을 담당하는 부분과 실제로 내용을 담고 있는 부분을 구분하는 가장 쉬운 방법은 같은 유형의 인스턴스 2, 3개를 비교하는 것이다. 만약 이렇게 할 수 없다면, 내용이 없는 부분이라고 생각하면 된다.로 나타나 있는 정보를 예로 들어 보자:
다음은 지금까지 변환한 문서이다:
이것은 유효한 XML 문서이긴 하지만, 아직은 구조가 너무 단조롭다. 정보를 보면, 어떤 엘리먼트는 서로 밀접하게 관련돼 있어서 컨테이너 엘리먼트로 그룹화해야 한다. 예를 들면, 앞의 8개 엘리먼트(부터 까지)는 보고서를 작성한 물리적 위치를 나타낸다. 그러므로 엘리먼트를 더해서 하나로 묶어 준다:
, , 과 엘리먼트는 행정상 용어이며, , 과 는 기하학적 용어이다. 그러므로 다음과 같이 하자.
데이터 정규화
이전에 정규화(normalization)는 관계형 데이터베이스를 디자인하는 사람이라면 반드시 알아야 할 개념이다. 단순한 개념이지만 SQL에 적용되었던 것과 마찬가지로 XML에도 적용된다. 즉 데이터를 중복하지 말하는 것이다. 정말 합당한 이유가 아니라면, 정보를 데이터베이스(혹은 문서)에 복사해서 저장하지 말자(데이터베이스에서는 성능과 관련된 작업으로 인해 중복할 때가 많다). 지금까지 작성한 문서에서 필요 없는 정보가 있는지 살펴보자.
엘리먼트
이 전체 컨테이너는 생략하고 ICAO 코드를 포함하는 단일 엘리먼트로 바꿔줘야 한다는 것은 자명하다. 엘리먼트 때문에 이 레코드를 다른 사람에게 보여 주고자 할 때마다 station을 찾아 봐야 하기 때문이다. 여기에서 생략하지 않는 이유는 어디까지나 성능과 관련되어 있기 때문이다.
엘리먼트
풍속은 법령과 속도의 두 가지로 표현되어 있으므로, 단일값(비행기 조종사??좀 더 친숙한 노트가 알맞다)으로 표현한다. 아직도 귀찮은 ":0"이 풍속 문자열에 붙여 있다. METAR 규약을 찾아서 ":0"이 무엇을 의미하는지 알아보지 않아도 된다. 필자 역시 "모르는 것은 그냥 놔둬라"라고 생각하면서 그러기 때문이다.
와 엘리먼트
이제는 시간대와 공항 위치를 알고 있으므로, UTC 정보만으로도 현지 시간과 날짜를 계산할 수 있다. 하지만 여기에서도 수행과 간소화를 위해서 필요 없는 정보도 써 주는 게 낫다. 그래야 나중에 사용자가 보기에 편하다.
, 와 엘리먼트
이 세 가지 엘리먼트는 두 가지 방법으로 측정되었다., 는 화씨와 섭씨 두 가지로, 는 수은주와 헥토파스칼(hPa)의 인치단위로 나타나 있다. 측량법은 모두 없애고, 단위를 엘리먼트 속성으로 바꾸자. 일정하게 표현하려면 약간의 부가적 과정이 필요하긴 하지만(사용자가 다른 측량법을 요구하는 경우), 텍스트 문자열을 수치로 바꿔줌으로써 앞으로 더 많은 옵션을 사용해 볼 수 있다.
고유키 확인
지금까지는 이 하나의 문서를 머릿속에서만 처리했다. 하지만 실제로 이 문서는 수천의 공항에서 매 시간 업데이트되는 보고서 중의 일부일 뿐이다. 이 문서를 유용한 컨텍스트로 만들려면, 다른 METAR 보고서와의 차이점을 부각시켜서, 이 정보를 필요로 하는 소비자에게 고유하다는 인식을 심어 줘야 한다.
언제, 어떤 정보를 XML 속성으로 코딩할 것인가에 관한 논쟁은 아직도 계속되고 있다. 한 XML 사용자 그룹에서는 XML 속성을 전혀 다루지 않는 Simple XML 스펙을 공식화하려는 시도도 했다. 다음의 내용은 내 개인적인 경험으로 분석한 것이니, 일반적인 사실로 받아들이지 말기를 바란다.
새로운 XML 문서를 개발하고 있을 때, 데이터베이스 다자인의 관점에서 생각해 보게 되었다. 그래서 문서 디자인의 기준을 완전히 새로 개발할 필요도 없거니와, 무엇보다도 대규모 데이터베이스를 디자인해왔던 내 경험 수준을 한 단계 높일 수 있었다. XML은 계층적 구조로 되어 있지만, 현대 데이터베이스의 대부분은 그렇지 않기 때문에, 매핑은 완벽하지 않다. 하지만 다음의 규칙은 항상 적용되었다.
4글자의 KCAE는 특정 공항에만 해당되는 고유한 것이기 때문에, 엘리먼트 요소로 포함하는 것은 location 축으로 해야 된다. 보고서는 전세계에서 들어오는 것이므로, 당분간은 UTC 날짜와 시간 필드를 선택하는 것이 가장 바람직하다. 또한 태그는 정보를 기입한다는 뜻이므로, 보고서의 내용과는 상관없다. 규정화 원칙에 따라, 이 데이터를 태그 안에 포함하면 문서의 바디에서는 이를 제거해야 된다.
이렇게 변경한 다음에는 여기를 클릭해서 최종적으로 바뀐 문서를 보자.
ICAO 위치 코드가 태그에 속성으로 포함되어 있음을 볼 수 있다. 우리가 데이터베이스에서 지칭한 바에 따라, 태그와 이에 들어 있는 컨텐츠는 KCAE에 의해 실제로는 다른 테이블에 속하게 된다. KCAE를 태그 내에 포함시킴으로써 관계가 더욱 분명해 지는 것이다. 여러 METAR 보고서를 처리하고, 엘리먼트를 뽑아내기 때문에, 완전한 위치 데이터베이스를 뽑아내는 업무를 단순화할 수도 있다.
요약
원래의 텍스트 파일로부터 잘 작성된 XML 문서를 만들기 위해 기초적인 사항을 설명했다. 실제 응용할 때에는 이보다 더 많은 작업을 거쳐야 한다. 일단 하나의 포맷이 만들어지면, DTD(문서 형 선언)를 해서 METAR 보고서를 유효화하는 것이 좋다. 그리고 이러한 변환 과정을 자동으로 수행하는 프로그램을 만들어야 한다는 것도 잊지 말자(아무리 빨리 입력한다 해도, 매 시간 1,000개 이상의 보고서를 일일이 업데이트하는 것은 손목뼈를 부러뜨리는 결과만 낳을 것이다).
비구조적 데이터를 XML로 변환하는 것은 아직은 과학이라기보다는 예술에 가깝다. 하지만 데이터베이스나 데이터 구조를 프로그램하는 등 이미 익힌 지식을 한 단계 높이는 것은, 맡은 일을 완성할 수 있는 툴을 갖게 되는 것이나 마찬가지다.
스콧 민즈(W. Scott Means)는 1998년, 17세에 마이크로소프트사에 들어가면서부터 전문 소프트웨어 개발자로 일해 왔다. OS/2 1.1과 Windows NT의 원 개발자이며, Advanced Technology and Business Development group에서 마이크로소프트 네트워크와 관련해서 초기에 여러 작업을 했다. 가장 최근에는 사우스캐롤라이나(South Carolina)에 있는 인터넷 인프라스트럭처 벤처인 Enterprise Web Machines의 CEO로 일하기도 다. 현재는 XML과 인터넷 관련해서 자문과 저작 활동을 하고 있다.
관련도서
장기적인 관점에서 봤을 때, 문서 형식을 XML로 바꾸어야 한다는 것은 이미 결론이 났지만, 아직 첨예한 문제 한 가지가 남아 있다. 이전의 문서는 어떻게 할 것인가이다. 옛 문서를 모두 저장해 놓고, 새로운 문서 작성에만 매달리면 아주 편하겠지만, IT 업계에서 모토로 삼고 있는 것은 급진적인 개혁이 아니라, 점진적인 발전이다. 그래서 옛 문서를 XML 형식으로 바꾸는 문제는 앞으로의 과제이다.
불행하게도 워드 프로세서 문서부터 스프레드 시트, 웹 페이지, 텍스트 파일에 이르기까지 비구조적인 문서는 너무 많다. 여기에 XML로의 변환 과정을 좀더 쉽게 할 수 있는 몇 가지 기술을 소개한다.
실제 예: 기상 예보
인터넷의 가장 큰 장점은 양질의 광대한 정보에 무료로 접근할 수 있다는 것이다. 미 정부 사이트도 이러한 무료 정보의 출처로 중요한 위치를 점하고 있다. National Weather Service에서는 기상 예보와 관측을 한다. 이러한 정보는 비행기 조종사가 비행할 때, 연방항공국(Federal Aviation Administration) 캐스터가 알려 주는 것과 동일하다. (자세히 알고 싶으면, METAR 보고서를 읽기 바란다.)
[편집자 주: METAR는 Aviation Routine Weather Report의 머릿글자를 따서 만든 말로, 불어에서 왔다.]
일례로 다음 URL에서는 컬럼비아 메트로폴리탄 공항(Columbia Metropolitan Airport)부근의 현재 기상 관측 사항을 다운로드할 수 있다.
ftp://tgftp.nws.noaa.gov/data/observations/metar/decoded/KCAE.TXT
매 시간 업데이트되긴 하지만, 우선은 이 정보로 작업을 해 보자:
Columbia, Columbia Metropolitan Airport, SC, United States (KCAE) 33-56-31N 081-07-05W 73M Mar 09, 2001 - 11:56 PM EST / 2001.03.10 0456 UTC Wind: from the N (010 degrees) at 5 MPH (5 KT):0 Visibility: 10 mile(s):0 Sky conditions: clear Temperature: 41.0 F (5.0 C) Dew Point: 36.0 F (2.2 C) Relative Humidity: 82% Pressure (altimeter): 29.98 in. Hg (1015 hPa) ob: KCAE 100456Z 01005KT 10SM CLR 05/02 A2998 RMK AO2 SLP152 T00500022 401170022 cycle: 5
[편집자 주: 첫째 행과 10번째 행은 문장의 길이가 길어서 다음 문장으로 넘어 갔다. 이 글에서는 이처럼 문장이 길어질 때 다음 문장의 첫 단어를 모두 들여쓰기할 것이다.]
소스 문서가 있으니, 이제 XML로 변환하자.
원자 엘리먼트 분리
실수로 물리학 입문 기사가 끼어 든 것은 아니니, 오해 없기 바란다. XML 문서는 엘리먼트로 구성되어 있어서 소스 문서를 변환하려면 어떤 구조로 되어 있는지 먼저 파악해야 한다.. 문서 정보에서 눈으로 볼 수 없는 가장 작은 조각이 XML 문서의 엘리먼트이다.
첫째 행부터 하나하나 살펴보도록 하자.
Columbia, Columbia Metropolitan Airport, SC, United States (KCAE) 33-56-31N 081-07-05W 73M얼핏 보면 이 행에는 여러 정보가 섞여 있다. 하지만 좀 더 자세히 보면, 기상 정보가 어디에서 수집된 것인지를 나타내는 물리적 위치임을 알 수 있다. 행의 맨 앞에 있는 위치를 보자. 일반적으로 사용하는 주소 체계이므로, 다음과 같이 코딩하면 된다.
그 다음에 있는 "KCAE"는 공항을 나타내는 것 같다. 어떤 단어의 약자인지를 알아내어 모두를 써 주거나, 나중에 혼란스러울 수도 있으니 METAR 사이트를 참조해서 적당한 용어를 찾는다. 일반적으로 XML을 새로운 방식으로 코딩할 때는, 그 결과가 현재의 프로젝트에만 머무는 것이 아님을 염두에 두어야 한다. 지금 정확한 단어를 찾아서 써 주는 수고를 하면, 나중에 자신이나 프로젝트의 후임자가 편하게 작업할 수 있다. KCAE라는 4개의 철자는 "국제 민간 항공 기구(ICAO)에서 지정한 위치"라는 뜻이므로, 다음과 같이 써 준다.Columbia Metropolitan Airport Columbia SC United States
이 행의 나머지 단어도 위와 마찬가지 방식으로 하면 된다(마지막에 있는 숫자는 평균 해수면을 기준으로 한 고도를 나타낸다)KCAE
다음 행을 살펴보기 전에, 하나의 행을 얼마나 잘게 엘리먼트로 쪼개야 하는지를 생각해 봐야 한다. 기술적으로는 위에서 코딩한 내용을 다음과 같이 할 수도 있다.33-56-31N 081-07-05W 73M
한 마디로 답하자면 다음과 같다: 지금 코딩하고 있는 문서를 읽을 독자를 생각하라는 것이다. 누가 이것을 볼 것인가? 위에 있는 모든 매개변수 값으로 쪼갤 필요가 있는가? 문서 길이가 적당한가? 위의 두 경우에서는 앞의 코딩이 더 압축되어 있다. 대개는 가장 작은 단위까지 쪼개면 되지만, 실제로는 어느 정도 융통성을 발휘해야 된다. 매 시간 수천에 달하는 보고서가 생기고 업데이트되고 있는 상황에서, 저장과 처리 요구가 까다로운 긴 문서를 누가 선호하겠는가?
드러나 있지는 않지만, 둘째 행의 코드는 관측 당시의 날짜와 시간을 나타내는 것이 분명하다. 이 행에서 눈 여겨 볼 것은 시간이 현지 시간과 협정 세계 표준시(UTC)의 두 가지 방식으로 표현되어 있다.
이제 나머지 부분은 코딩하기 쉽다. 위와 같은 방식으로, 콜론으로 분리된 라벨과 값을 표시하면 되는 것이다. 이러한 문서를 코딩하는 가장 쉬운 방법은 원래의 필드 라벨을 XML 엘리먼트의 태그 네임으로 사용한다.Mar 09, 2001 11:56 PM EST 2001.03.10 0456
from the N (010 degrees) at 5 MPH (5 KT):0 10 mile(s):0 clear 41.0 F (5.0 C) 36.0 F (2.2 C) 82% 29.98 in. Hg (1015 hPa) KCAE 100456Z 01005KT 10SM CLR 05/02 A2998 RMK AO2 SLP152 T00500022 401170022 5
스콧 민즈는 oreilly.com에서 What"s New in the DOM Level 2 Core? (한빛 사이트: DOM Level 2 Core의 새로운 특성은 무엇인가?)라는 XML 관련 기사도 쓴 바 있다. DOM Level 2는 2000년 11월 공식적인 W3C의 권고안이 되었다. 이 기사에서는 DOM(Document Object Model)을 소개하며, DOM 개발자에게 새로운 Level 2의 특성을 안내해 준다.
컨텐츠에서 프리젠테이션 분리
일반적으로 문서에서 가독성과 미학적인 측면을 담당하는 부분과 실제로 내용을 담고 있는 부분을 구분하는 가장 쉬운 방법은 같은 유형의 인스턴스 2, 3개를 비교하는 것이다. 만약 이렇게 할 수 없다면, 내용이 없는 부분이라고 생각하면 된다.
"from the N" 뒤에는 실제로 풍향을 측정한 방향(010 degrees)이 나와 있다. "from the N"보다는 "010 degrees"가 더 정확한 수치이므로, 굳이 "from the N"을 써 행 필요는 없어 보인다. 그러므로 wind에 대해서는 더 간결하게(동시에 더 유용하게) 다음처럼 표현하는 것이 낫다.from the N (010 degrees) at 5 MPH (5 KT):0
구조적 엘리먼트 더하기5 MPH (5 KT):0
다음은 지금까지 변환한 문서이다:
물론 XML 문서는 최상위 레벨에 단 하나의 엘리먼트만 있을 수 있다. 그래서 최상위 레벨 엘리먼트와 XML 선언을 해주면 XML문서가 완성된다(XML 문서를 보려면 여기를 클릭하자).Columbia Metropolitan Airport Columbia SC United States KCAE 33-56-31N 081-07-05W 73M Mar 09, 2001 11:56 PM EST 2001.03.10 0456 5 MPH (5 KT):0 10 mile(s):0 clear 41.0 F (5.0 C) 36.0 F (2.2 C) 82% 29.98 in. Hg (1015 hPa) KCAE 100456Z 01005KT 10SM CLR 05/02 A2998 RMK AO2 SLP152 T00500022 401170022 5
이것은 유효한 XML 문서이긴 하지만, 아직은 구조가 너무 단조롭다. 정보를 보면, 어떤 엘리먼트는 서로 밀접하게 관련돼 있어서 컨테이너 엘리먼트로 그룹화해야 한다. 예를 들면, 앞의 8개 엘리먼트(
위치 정보는 다시 나뉘어 질 수 있다.Columbia Metropolitan Airport Columbia SC United States 33-56-31N 081-07-05W 73M
이러한 관계를 나타내는 것이 나중에 가서는 문서를 나타내거나 처리하는 업무를 단순화해 준다.Columbia Metropolitan Airport Columbia SC United States 33-56-31N 081-07-05W 73M
데이터 정규화
이전에 정규화(normalization)는 관계형 데이터베이스를 디자인하는 사람이라면 반드시 알아야 할 개념이다. 단순한 개념이지만 SQL에 적용되었던 것과 마찬가지로 XML에도 적용된다. 즉 데이터를 중복하지 말하는 것이다. 정말 합당한 이유가 아니라면, 정보를 데이터베이스(혹은 문서)에 복사해서 저장하지 말자(데이터베이스에서는 성능과 관련된 작업으로 인해 중복할 때가 많다). 지금까지 작성한 문서에서 필요 없는 정보가 있는지 살펴보자.
이 전체 컨테이너는 생략하고 ICAO 코드를 포함하는 단일 엘리먼트로 바꿔줘야 한다는 것은 자명하다.
풍속은 법령과 속도의 두 가지로 표현되어 있으므로, 단일값(비행기 조종사??좀 더 친숙한 노트가 알맞다)으로 표현한다. 아직도 귀찮은 ":0"이 풍속 문자열에 붙여 있다. METAR 규약을 찾아서 ":0"이 무엇을 의미하는지 알아보지 않아도 된다. 필자 역시 "모르는 것은 그냥 놔둬라"라고 생각하면서 그러기 때문이다.
이제는 시간대와 공항 위치를 알고 있으므로, UTC 정보만으로도 현지 시간과 날짜를 계산할 수 있다. 하지만 여기에서도 수행과 간소화를 위해서 필요 없는 정보도 써 주는 게 낫다. 그래야 나중에 사용자가 보기에 편하다.
이 세 가지 엘리먼트는 두 가지 방법으로 측정되었다.
예를 들어, temperature와 dew point를 수치로 코딩하면, 변환 스크립트는 이 둘을 비교해서 카뷰레터 냉각기에 발생할 수 있는 경고를 띄울 수 있다. 보고서의 전체 사이클은 쉽게 온도 변화 추이를 감지할 수 있도록 처리해야 한다.41.0 36.0 29.98
고유키 확인
지금까지는 이 하나의 문서를 머릿속에서만 처리했다. 하지만 실제로 이 문서는 수천의 공항에서 매 시간 업데이트되는 보고서 중의 일부일 뿐이다. 이 문서를 유용한 컨텍스트로 만들려면, 다른 METAR 보고서와의 차이점을 부각시켜서, 이 정보를 필요로 하는 소비자에게 고유하다는 인식을 심어 줘야 한다.
언제, 어떤 정보를 XML 속성으로 코딩할 것인가에 관한 논쟁은 아직도 계속되고 있다. 한 XML 사용자 그룹에서는 XML 속성을 전혀 다루지 않는 Simple XML 스펙을 공식화하려는 시도도 했다. 다음의 내용은 내 개인적인 경험으로 분석한 것이니, 일반적인 사실로 받아들이지 말기를 바란다.
새로운 XML 문서를 개발하고 있을 때, 데이터베이스 다자인의 관점에서 생각해 보게 되었다. 그래서 문서 디자인의 기준을 완전히 새로 개발할 필요도 없거니와, 무엇보다도 대규모 데이터베이스를 디자인해왔던 내 경험 수준을 한 단계 높일 수 있었다. XML은 계층적 구조로 되어 있지만, 현대 데이터베이스의 대부분은 그렇지 않기 때문에, 매핑은 완벽하지 않다. 하지만 다음의 규칙은 항상 적용되었다.
- 말단 엘리먼트(Leaf elements) - 필드: 하나의 말단 엘리먼트는 데이터베이스의 테이블 한 칼럼에 저장되는 정보를 담고 있다.
- 말단의 집합(Collections of leaves) - 열: 이 예에서는 전체
엘리먼트가 하나의 데이터베이스 테이블의 한 열에 해당한다. - 집합의 집합(Collections of collections) - 테이블: 여러 개의
엘리먼트가 하나의 문서에 저장되면, 이를 담고 있는 컨테이너는 데이터베이스 테이블에 해당된다. - 속성 - 키와 인덱스: XML에서 정의하는 ID 메커니즘 때문에 어떤 속성은 XML 문서 내에서 아주 "고유한 키"로 되었다. 문서를 좀 더 일관되고, 유형은 같지만, 서로 다는 엘리먼트라는 것을 명백히 보여주기 위해, 필자의 경우에는 속성 면에서 엘리먼트를 고유하게 해 주는 모든 데이터를 표기한다. XML의 ID 메커니즘으로 이러한 관계를 좀 더 명백하게 만들어 주는 것도 좋지만, ID와 IDREF 속성 값에 제한이 있기 때문에 할 수 없을 때도 있다.
- 집합의 집합(Collections of collections) - 테이블: 여러 개의
4글자의 KCAE는 특정 공항에만 해당되는 고유한 것이기 때문에,
이렇게 변경한 다음에는 여기를 클릭해서 최종적으로 바뀐 문서를 보자.
ICAO 위치 코드가
요약
원래의 텍스트 파일로부터 잘 작성된 XML 문서를 만들기 위해 기초적인 사항을 설명했다. 실제 응용할 때에는 이보다 더 많은 작업을 거쳐야 한다. 일단 하나의 포맷이 만들어지면, DTD(문서 형 선언)를 해서 METAR 보고서를 유효화하는 것이 좋다. 그리고 이러한 변환 과정을 자동으로 수행하는 프로그램을 만들어야 한다는 것도 잊지 말자(아무리 빨리 입력한다 해도, 매 시간 1,000개 이상의 보고서를 일일이 업데이트하는 것은 손목뼈를 부러뜨리는 결과만 낳을 것이다).
비구조적 데이터를 XML로 변환하는 것은 아직은 과학이라기보다는 예술에 가깝다. 하지만 데이터베이스나 데이터 구조를 프로그램하는 등 이미 익힌 지식을 한 단계 높이는 것은, 맡은 일을 완성할 수 있는 툴을 갖게 되는 것이나 마찬가지다.
스콧 민즈(W. Scott Means)는 1998년, 17세에 마이크로소프트사에 들어가면서부터 전문 소프트웨어 개발자로 일해 왔다. OS/2 1.1과 Windows NT의 원 개발자이며, Advanced Technology and Business Development group에서 마이크로소프트 네트워크와 관련해서 초기에 여러 작업을 했다. 가장 최근에는 사우스캐롤라이나(South Carolina)에 있는 인터넷 인프라스트럭처 벤처인 Enterprise Web Machines의 CEO로 일하기도 다. 현재는 XML과 인터넷 관련해서 자문과 저작 활동을 하고 있다.
관련도서
TAG :
이전 글 : 발톱이 부부의 "Shall we samba?"(중)
최신 콘텐츠