한빛출판네트워크

by xml-doc 메일링 리스트를 관리하는 Miachel Smith, 역 한빛리포터 2기 이상훈 차례

• 새로운 학습과정
  • XML을 배우지 말라고?
  • 강의 1: XML은 HTML이 아니다.
  • 강의 2: 기술이 아닌 업무
  • 강의 3: 더 나은 길이 있다.
• 결론

당신이 XML의 개발자로서 데이터 지향적인 면에만 관심이 있고, 책, 기사, 매뉴얼, 시, 웹 문서 등등의 저작에는 관심이 없다면 이 기사는 가차없이 무시해도 된다. 반면에 문서 저작이 당신(기술문서 작성자, HTML 마크업 문서 저술가, 문서그룹의 매니저, 무명의 팜플렛 작성자 등등)에게 중요한 일이라면 XML을 배워서 문서를 작성하는데 사용하는 것이 가치가 있는지를 결정하려고 노력하고 있을 것이며, 또한 계속 이 기사를 읽을 필요성이 있다. 여기서 배우게 될 내용은 불필요한 불만에서 당신의 노력과 시간을 덜어줄 것이다. 새로운 대안으로서의 학습법 아마도 여러분은 XML기반의 문서저술에 따른 장점에 대한 다음과 같은 많은 광고성 얘기를 들어봤을 것이다. 예를 들어, "자체기술 데이터(self-describing data)", "표현과 내용의 분리(separate content from presentation)", "단일 원본을 이용한 작업(single-sourcing)"과 같은 것들이다. 장점을 어떻게 부각시키는가와 상관 없이 위에 나온 얘기는 기본적으로 같은 목적을 의미한다: 이러한 방식으로 문서 내용을 생산하는 개념은 보다 쉽게 저장하고 여러가지 목적으로 재사용할 수 있게 해준다는 것이다. 일반적인 예로서 동일한 원본 내용에서 다수의 전달형태(HTML, PDF, online help 등)를 생성하는 것이다. 이제 여러분이 지금 수행하고 있는 문서 저술 접근법(공개 소스 도구이거나, Adobe FrameMaker 혹은 Microsoft Word와 같은 애플리케이션을 사용하는 것)을 살펴보면, 심각한 한계를 가지고 있다는 것과 수없이 들어왔던 우아한 "단일 원본" 같은 것을 제공하는 것과는 거리가 멀다는 것을 알 수 있을 것이다. 따라서 당신은 이러한 기능을 제공하는 저술법에 대해 배우고 싶을지도 모른다. 맞는가? 그렇다면 당신에게는 "XML을 배우지 마라"라는 말이 가장 좋은 충고일 것이다. XML을 배우지 말라고? 왜 XML을 배우지 않는가? 대답은 다음과 같다: XML을 배우기란 복잡한 일이고, HTML을 배우는 것보다 훨씬 더 까다로운 잡일이기 때문이며 여러분이 단지 문서저술을 위한 보다 나은 시스템을 찾는 것이라면 몰두할 필요도 없기 때문이다. 따라서 새롭게 XML을 배우는 것 보다 세 개의 쉬운 강의로 꾸민 대안 학습 방식을 전적으로 따를 것을 권하는 바이다. 만약 여러분이 숙달된 학습자이기에 앞에 있는 두개의 강의가 따분하다면 모든 것을 무시하지 말고 단지 강의 3으로 건너 뛰면 된다(그 다음에 무시해도 된다). 여러분이 진짜 해결해야 할 문제를 찾는 것이 아니라면 각주를 많이 참조하는 것도 도움이 될 것이다. 강의 1: XML은 HTML이 아니다. HTML에 대한 배경지식을 가지고 있으므로 HTML을 습득하는데 걸린 시간과 노력을 조금 더 기울인다면 쉽게 XML을 배울 수 있을 거라고 가정하는 것은 설득력 있어 보일지도 모른다. 그러나 불행히도 전혀 그럴듯한 가정이 아니다. XML을 배운다는 것은 생각하는 것 이상의 훨씬 더 많은 시간과 노력을 요구한다. 무슨 말인지는 다음의 간단한 연습문제를 풀어보면 알 수 있다: 연습: X를 세어보라 이 강의를 위한 연습문제는 두, 세권 정도의 XML 입문서의 차례를 살펴보고 대문자 X로 시작하는 단어나 문장(XSLT, XPath 등)을 적어 보는 것이다. 그런 다음 X없는 약자 단어(DOM, PDF 등)를 적어보라. 최소한의 목록을 채우고 나면 다음과 같은 결과를 얻을 수 있을 것이다:

XSLT, XPath, XSL-FO, XPointer, XLink, XBase, XInclude, XML Schema, XQuery, XHTML, DTDs, DOM, SAX, RDF, CSS

이 시점에서 목록에 있는 항목들 중 몇몇에 대해 최소한의 탐색을 해 보았다면 그 중 어느 것도 XML의 부분이라고 말할 수 없다는 것을 쉽게 발견했을 것이다. 대신에 그것들은 모두 기술에 관련된 것으로, 각각은 XML 자체의 기술명세와는 별개인 매우 어려운 기술명세를 정의하고 있다(그것들을 인쇄해서 가지고 가려면 손수레가 필요할 정도이다). 예를 들어 보면 DTDs와 CSS는 실제 XML에 선행하는 기술이며. XSLT는 완전히 자립한 프로그램 언어이다. 따라서 HTML을 배우는 것과 비교하는 식으로 XML에 접근하지 말아라: HTML을 배우고 활용하기 위해서는 한정된 태그세트

, 등과 익숙해지기만 하면 되었다. 그러나 XML과 어느 정도 친숙해지려면 DTDs와 XSLT와 같은 어려운 관련 표준이나 기술의 집합과 친해져야 하고 그러한 도전은 전적으로 자신의 책임하에 이루어지는 것이다. 따라서 스스로가 무엇을 배워야 할 것인가에 대한 고려 없이 XML을 배워보자고 하는 것은 엄청난 시간낭비가 될 수도 있다. 강의 2: 업무는 기술이 아니다 XML과 관련된 혼돈과 복잡성을 줄이기 위해 그것을 배우기를 원하는 실제적인 이유를 돌아보는 시간을 가져보자. 다른 표준과 마찬가지로 여러분 개개인이 실질적인 용도에 적용을 할 수 없다면 다른 사람들에게도 아무 소용이 없는 것이다. 따라서 어떤 특정한 업무를 상기하고 어떤 이유에서 XML이 그 업무를 수행하는 도움이 될 수 있는가를 생각하자. 여러분이 실질적으로 보여주고자 하는 목적인 다이어그램이나 표 등등의 것들이 XML과 주요 관련기술로 구현된다는 것을 상상해보는 것은 멋지지 않은가? 그렇다면, 필자에게 찬사를 보내기를... 왜냐하면 여러분은 handy¹라는 실질적인 면을 설명하는 표를 볼 수 있기 때문이다.

표 1. 목적별로 구분한 XML 관련 표준과 기술

목적	표준 혹은 기술
저술, 구조, 실증	XML, SGML, DTDs
조판과 출판	CSS, DSSSL, XSL-FO, XHTML
변환	XSLT
연관성	RDF, XTM (XML Topic Maps)
관계	XLink, XBase, XInclude
탐색	XPath, XPointer, XQuery
프로그래밍	SAX, DOM

바라건데, 이 표 ²에 있는 정보가 목적별로 XML과 관련 표준과 기술을 머리 속에 있는 특정 업무와 관련 있는지 없는지 쉽게 알 수 있었으면 하고 XML이 도움이 될 것인지를 더 쉽게 파악하는데 도움이 됐으면 한다. 일단 그러한 일을 마쳤으면 다음 단계는 배움의 길을 어떻게 밝힐 것인가를 생각하는 것이다. 다음의 연습이 도움이 될 것이다. 연습: 스스로에게 질문하기 이 강의의 연습은 표 1의 정보를 이용해서 몇 개의 간단한 질문을 스스로에게 해보는 것이다:

• 지금 수행중인 어떤 종류의 프로그래밍(진짜 프로그래밍)이나 애플리케이션 개발 업무가 XML을 이용해서 더 나아질 수 있을까? 힌트: 현재 아무런 프로그래밍 업무가 없다면 XML은 비프로그래밍 업무를 수행하는 데도 더 나은 도움이 되지 않을 것이다.
• 현재 만들고 있는 애플리케이션에는 어떠한 링크와 탐색기능이 있는가? 힌트: 당신이 문서 저술가라면 대답은 "없다"이다. 링크와 탐색 기술은 문서 레벨 제어 작업이 아니다: 그러한 기능은 문서 저술, 저장, 표시와 같은 애플리케이션에서 구현할 일이다. 그러한 기능에 대한 XML관련 기술을 습득하는 것도 전혀 나쁜 일은 아니다. 그러나 짧게 말해서 문서 저술 업무를 조금도 빠르게 하는데 도움이 되지는 않을 것이다.
• 문서 혹은 문서간의 매우 의미론적으로 연관 있는 표준이 있는가? 힌트: 여러분이 그와 같은 질문과 관련된 업무를 수행하고 있다고 확신할지라도 지금으로선 할 말이 없다. 왜냐하면 그것은 또 다른 하나의 기사의 주제에 해당하는 방대한 내용이기 때문이다.

표 1을 참조한 질문과 XML에 대한 고려와 특정 목표라는 용어를 사용한 주요한 전략은 여러분에게 XML이 가장 실용적인 응용으로서 문서 저술, 구조, 변화, 조판, 출판으로 표준 혹은 기술로 결정하도록 것이었다. 만약 이런 내용들이 여러분이 하는 일에 대한 설명이었다면 XML에 대한 더 이상의 검토는 그만 둘 수 있다. 말이 되풀이 되지 않도록 하기위해 한 번 더 말하는데 여러분은 XML을 배울 필요가 없다. 그와 같은 용도로 XML을 배우는 것은 과도한 기술을 습득하는 것이다. 다시 말하면, 여러분이 하는 종류의 일과 직접적으로 관련이 없는 방대한 정보에 불과하다. 여러분은 더 많은 시간을 현재 수행중인 문서 저술 작업과 직접 연관된 시스템(더 좋은 말이 없기 때문에)-그러한 시스템이 있다면-을 배우는데 사용하는 것이 훨씬 나을 것이다. 파이프 꿈(연결성에 대한 바램) 여러분이 매우 구조화된 문서 작성할 수 있는 설계를 가능하게 하는 특정 시스템이 있다고 상상해 보자, 또한 HTML, PDF 파일과 같은 형태로 여러분의 작성한 내용을 변환, 조판, 출판 할 수 있는 "off the shelf" 지원을 한다고 해보자. 이 연결성에 대한 바램이 가능하기만 하다면 좀 더 많은 상상을 할 수 있지 않겠는가: 우리의 시스템이 이미 광범위하게 설치되어 운영되고 있고(따라서 초기의 도입과 걱정 잡무는 고려할 필요가 없다), 오랫동안 그러한 일을 위해 일해온 다른 사용자들로부터 지원을 더 이상 받을 필요가 없다고 해 보자. 나는 여러분이 약간의 수사학과 추측을 통해서(앞서 알고 있지는 못했다 하더라도) 그러한 시스템이 이미 존재한다는 것을 보았으리라 확신한다. 실제로 몇 가지의 앞서 나온 조건을 만족하는 구조화된 저작 시스템(혹은 파생물, 그렇게 부르기를 원한다면)이 나와있다. 그 중에 그러한 조건들을 유별나게 잘 만족시키는 마크업 파생물(Markup dialect)이 있는데, 다른 구조화 저작시스템 변종³들과 비교 검토하는 벤치마크에 들어가 있다. 그 표준이 DocBook이다⁴. 강의 3: 더 나은 길이 있다 확신하건데 여러분은 이미 많은 분량의 XML을 배워야 하는 가치에 대해서 들어왔을 것이다. 그래서 DocBook, TEI⁵ 혹은 다른 특화된 마크업 파생물(Markup dialect)을 배우는 것이 여러분이 찾고 있던 문서저작 솔루션으로의 가장 최선의 길이라고 단순히 믿게 만들거나 내 말을 수용할 것을 기대하지 않는다. 감히 단정 짓는다면 여러분은 아마도 좀 더 상세한 것을 알고 싶어할 것이다. 따라서 이 번 강의 후반에는 필자가 선호하는 파생물(dialect)인 DocBook활용을 예제로 제공할 것이다. 먼저 DocBook이 무엇인가에 대한 정보를 다른 변종들과의 차이를 자세히 보여줄 것이다(TEI에 대해서 좀 더 알고 싶다면 Text Encoding Initiative 웹 페이지를 방문해 보라). DocBook은 무엇인가? DocBook은 간단하게 말해서 HTML과 같은 마크업 파생물(혹은 어휘⁶)이다. 그리고 HTML과 마찬가지로 DocBook은 DTD 혹은 document type definition으로 정의 된다. DTD는 어떤 요소와 속성이 어디에서 사용되어져야 하는 것에 대한 제어를 하는 content models이라고 불리는 규칙들을 정의한다. 예를 들어, DocBook DTD는 HTML DTD에서

태그를 문장정의에 이용하듯이 태그를 문장을 마킹하기 위해 정의한다. 그리고 HTML에서처럼 DocBook 문서는 만들거나 편집하기 위해 어떤 특별한 도구를 필요로 하지 않는다. DocBook 작업을 매우 편리하게 해주는 특별한 편집 응용 도구들이 있음에도 불구하고 HTML 문서를 작성 하는 것과 마찬가지로 메모장, 혹은 다른 어떤 단순한 텍스트 편집기를 쓰더라도 DocBook 문서를 만들 수 있다. DocBook이 어떤 형태로 나타나는가를 보여주기 위해 이 기사에서 DocBook으로 마크업된 각주 1을 예제로 나타냈다.

The initial basis for the taxonomy in was the Taxonomy of Standards appendix in Erik T. Ray’s &url.learnx;, though the grouping/labeling in differs quite a bit from Ray’s, and it adds some non-&w3c; technologies. So, if you disagree with the table, you’ve only got me to blame. And if you really disagree with it, hey, come up with your own table, and we’ll see if we can get a senate subcommittee to evaluate which one’s better.

몇 개의 태그를 설명하자면: 는 HTML의

태그와 비슷하다. 는 HTML의 요소와 딱 들어맞는 건 없지만 태그와 약간은 닮았다. 그리고 과 는 HTML의 와 태그와 비슷하다. 앰퍼샌드(&)로 시작되는 다른 태그들은 사용되는 곳에서 정의되어지는 대로 다양하게 작동하는 제너럴 엔티티들이다. 일예로 제너럴 엔티티 세트인 ’는 오른쪽 따옴표(")로 정의된다(유니코트 문자 넘버 2019). 예를 들어 또 다른 엔티티인 &url.learnx;과 &w3c;을 살펴보자. 이 둘은 사용자 정의형 엔티티로 내가 사용하는 방식대로 정의할 수 있다. 일예로 &url.learnx;는 다음과 같이 정의 내릴 수 있다. Learning &xml; 이 하이퍼 링크는 Erik T. Ray가 저작한 『Learning XML』의 웹 카탈로그 사이트로 HTML 문서의 앵커와 똑같다. 그런데 만약 DocBook이 HTML과 비슷하기만 할 뿐이라면 굳이 HTML 대신에 DocBook을 사용하고 싶어하는 이유가 있을까? 간단하게 답을 말하면 DocBook은 심도 있게 구조화된 문서를 마크업하는데 실용적이지 못 한 HTML과 다르다는 것이다. 즉 DocBook은 모든 종류의, 더 정확하게는 컴퓨터 소프트웨어와 하드웨어에 관련된 문서들을 구조적을 마킹하도록 특별히 설계되어 있다. 기본적으로 DocBook은 흔히 "단일원본(single-sourcing)" 혹은 "형식과 내용의 분리(separate content from presentation)"⁷라고 불리는 방법인 사용자가 맞출 수 있도록 재사용하고 저장할 수 있는 컨텐츠 마킹의 수단을 제공하도록 하는 기반에서 만들어졌다. DocBook이 무엇인가에 대해 한마디로 말하자면 매우 강력한 HTML이라고 할 수 있다. 여러분이 찾고 있던 무언가처럼 들리고 당장 시작하고 싶어 안달이 난다면 첫번째 단계 부분으로 건너 뛰어도 된다. DocBook 저작 시스템 설치와 그것을 이용하기 시작하는 것에 대한 전체적인 입문서를 제공하는 것은 이 기사의 범주를 벗어나는 것이지만, 이 절에서는 여러분의 시작을 도와줄 문서 링크와 입문서를 제공한다. 반면에 DocBook의 세계로 뛰어들 결정하기 전에 일반적인 XML을 배우는 것과 비교해서 다른 대안을 찾아보는 것과 DocBook이 어떤 차이점을 가지고 있는지 그리고 DocBook을 배우는 이점에 대해 생각하는 데 좀 더 시간을 소비해야 할 필요도 있다. 따라서 필자가 그 배경을 설명하는데 필요한 몇 분의 시간을 내어보도록 하자. 표준과 변종들 기본적으로 DocBook은 사실상 기술문서 구조화 작성에 관한 표준이 되어왔을 뿐만 아니라 많은 다른 형태의 구조화된 문서 작성에도 사용되고 있다. 그러나 몇몇 사람들은 DocBook같은 표준을 배울 가치에 대해서 의문을 제시한다⁸. 예를 들어, 전적으로 사적이고 비공개 된 소스 응용에 관한 문서를 작성하는 경우를 고려해 보자. 여러분은 그러한 문서를 작성하는 작성자나 관리자들이 공개 구조화 저작 표준을 배우고 사용하는 가치에 대해서 지나치게 신경 쓰는 것을 기대하지 않을 것이다. 결국, 그들이 작성한 문서를 자사직원이 아닌 그 누구와도 교환하게 될 필요가 없을 것이다. 그리고 정확하게 그들의 요구에 부합하는 DTD를 만들기 위해서 XML/SGML 전문가의 컨설팅을 받을 수 있는 예산을 마련하는 것도 가능할 것이다⁹. 그래서 그런 경우는 DocBook에 대한 대안으로서 맞춤형 DTD를 개발하는 것이다. 사실은 기술문서의 경우, DocBook에 대한 실제적인 대안은 모두 스스로의 용도에 맞게 설계된 상이한 문서 shops인 내부용 DTD들이다. 그런 회사별 특정 DTD와 함께 나타난 대안들은 나쁜 생각처럼 들리지 않을 수 있으나 많은 경우에 그렇지 않을 수도 있다. 그러나 DocBook 대신 맞춤 DTD를 고려할 때는 새로운 작성자를 교육시키는 것과 같은 다른 비용과 주의를 기울여야 한다는 것을 기억해야 한다¹⁰. 예를 들어, 맞춤 내부용 DTD를 기반으로 한 문서 저작시스템을 구축한 회사의 경우 그들의 DTD에 이미 익숙한 신입사원을 고용한다는 가능성은 거의 없다(왜냐하면 그 회사만 그런 시스템을 쓰고 있기 때문이다). 따라서 신입사원에게 그들의 특정 DTD를 교육하는데 비용이 든다. 반면에, 이미 DocBook을 습득한 사람을 고용할 가능성은 매우 높다. 이미 수천명의 DocBook 기술을 가진 사람을 선택할 수 있고 그 숫자는 매일 늘어나고 있다. 그러므로, 변종 DTD를 하기로 결정하기 전에 나머지들과 별도로 DocBook에 대해 정리할 시간을 고려해 볼만한 것이다. 무엇이 DocBook을 차이 나게 하는가? 우호적인 다수의 사용자를 가져다 준 DocBook의 기능에는 다음과 같은 이유가 있다:

• HTML, PDF 파일과 Tex, RTF, FrameMaker MIF, JavaHelp, Microsoft HTML Help, Unix man pages, Texinfo 등 여러 다양한 형태의 내용에 대한 변환, 조판, 출판을 위한 고난이도의 즉각 사용 가능한(off-the-shelf) 지원과 연계
• 전체적으로 문서화 됨(Norman Walsh와 Leonard Muellner의 DocBook: The Definitive Guide 중에서)
• 썬, 휴렉 펫커드, 노벨, SCO 그리고 Red Hat 등의 영리단체와 KDE, GNOME, FreeBSD, Debian, Linux 문서 프로젝트(LDP) 등의 비영리 단체 뿐만 아니라 Darwin 문서화 프로젝트(Darwin은 애플의 Mac OS X의 핵심적인 오픈소스 진영이다)등의 전세계적인 생산시스템에서 광범위하게 이식되고 심도 있게 테스트됨
• 이 분야에 수년간 일을 해 온 수천명의 사용자 망의 전폭적인 지원
• 오픈소스적 개념에 튼튼한 기반을 둠: DocBook은 애플리케이션 지원을 위한 이식이나 사용하기 위해 주의를 기울일 필요가 없다. 독자적인 사용을 위해서 허락을 요청할 필요가 없고, 변경된 사항을 재배포 할 때도 자유롭다.
• Norman Walsh, Eve Maler, Jon Bosak외에 다수를 포함하는 XML과 SGML 진영의 주요한 권고를 수용해서 10년 이상 활발하게 개발되고 개선되어 왔다¹¹.
• 기초부터 심도 있게 커스터마이징을 지원하도록 설계되어있기 때문에 여러분의 특정요구에 맞게 재 가공되었거나 할 수 있다.
• 다수의 문서저작 애플리케이션을 일반적으로 지원한다: 다수의 상업용 편집과 출판도구 벤더들이 애플리케이션에 내재된(built-in) DocBook 지원 기능을 지원하고, Debian의 task-sgml, docbook-tools 패키지(RPMs)와 Paul Kinnucan의 XAE 등 다수의 오픈소스 패키지들도 DocBook을 지원하도록 결합할 수 있다.
• 완벽한 XML/SGML 기반과 100% XML/SGML호환성: 일반적으로 XML과 SGML에 대해 여러분이 들어왔던 장점은 DocBook에 관한 것이라고 단호히 말할 수 있다.

성과 DocBook을 바라보면서 내가 바란 것은 XML을 배우는 것과 특정 파생물을 배우는 것에 커다란 차이가 있고 일반적으로 XML을 공부하기위해 노력하는 것보다 DocBook과 같은 특정한 마크업 파생언어를 배움으로써 XML기반 구조화 저술로의 탐험을 시작하는 것이 훨씬 낫다는 것을 분명히 하기위해 노력했다. 그러나 이 기사의 제목이나 논조와는 달리 XML이나 XSLT를 포함한 나머지 것들에 대해 여러분이 전적으로 배울 필요가 없다는 것을 제시한 것을 아니다¹². 실제로 DocBook을 더 많이 이용함에 따라 더욱 많은 것을 배울 필요가 있을 것이다. 하지만 여러분의 나가는 방향에 따라 필요한 것을 배울 수 있다. 가능한한 정직하게 주장하건데 DocBook으로 시작하라고 하는 가장 좋은 이유는 그것이 당장 성과를 낼 수 있다는 것이다. 문서 저자로서 DocBook을 습득함으로써 당장 이익을 가져올 수 있는데, 왜냐하면 컴퓨터 소프트웨어나 하드웨어에 관한 저술과 같은 종류의 일을 수행하고 있다면 배운 것을 바로 적용할 수 있기 때문이다. 일하면서 배우기 내가 생각하기에 XML과 DocBook을 배우는 차이는 SGML과 HTML을 배우는 차이와 비교하는 것이 좋을 것이다¹³. 여러분이 HTML을 배운 방식에 대해 생각해보라: SGML에 관한 책을 사기위해 서점에 들리지 않았을 것이다. 실제로 여러분은 HTML이 SGML에 기반을 둔 것을 몰랐거나 신경 쓰지 않았을 것이다. 그래서 내가 보기엔 공식 HTML 스펙을 읽기 위해서 SGML의 ISO 스펙을 읽거나 W3C의 웹사이트를 방문해야만 했을 것이라는 것은 아니었을 것이다. 대신에 여러분이 만들고 싶은 것과 비슷한 다른 사람의 웹 페이지를 복사하는 것에서부터 시작했을 것이다. 다른 페이지의 일반적인 구조를 본 다음 "맞아, 이제 어떻게 하는지 살펴보자"라고 말한 다음 필요에 따라 구조를 조절하고 자신만의 내용을 추가했을 것이다. 그리고 여러분의 첫번 째 HTML문서를 완성했을 것이다. 나는 비슷한 방법으로 XML을 배울 것을 제안한다. 실제로 사용하고 즉 당장 DocBook을 이용해서 여러분의 구조화된 문서를 작성하는 것이다. 첫 번째 단계 이것은 DocBook을 사용하는 입문서는 아니지만 여러분에게 필요한 첫 번째 단계에 대한 짧으나마 상세한 면을 제공하고 다른 자료에 대한 약간의 입문서를 제시하고자 한다. DocBook을 배우는 첫 단계는 간단하다: DocBook을 위한 문서를 선택하고 XML이나 SGML 편집 애플리케이션¹⁴ 을 구하고 바로 첫 번째 문서를 만들기 시작하는 것이다¹⁵. 문서와 입문서들 DocBook은 Norman Walsh와 Leonard Muellner의 DocBook에 전체적으로 문서화 되어있다. 『DocBook: The Definitive Guide』라는 책으로 인쇄된 것과 (필수적으로 가지고 있어야 한다) 온라인 텍스트 버전이 있다. 게다가 DocBook에는 수십 개의 예제와 아주 상세한 참조물들이 부수적으로 나온다. 『DocBook: The Definitive Guide』는 DocBook을 시작하는데 필요한 기본적인 정보를 제공하는 것과 더불어 XML/SGML의 개념에 대한 속성 소개와 간단한 다음과 같은 "how to"정보를 제공한다.

• DocBook에 관한 기사, 챕터, 책 혹은 참조 페이지를 모음
• 작성한 문서를 검증하고 닥치게 될 에러 메시지를 해석함
• DSSSL을 이용한 문서 출력
• 특정한 요구에 부합하도록 DocBook DTD를 재구성함

매우 유용한 정보로 Erik T. Ray의 『XML 시작하기』 2장, "마크업과 주요 개념"에 대한 것이 있다. 완전한 DocBook 문서의 주석판 예제를 포함하는 XML 기본을 충실하게 반영하는 부분이다. 또한 5장 "문서 모델: 더 높은 수준의 문서 제어"도 충분히 읽을 가치가 있다. DocBook의 부분집합인 DTD의 주석판 예제를 포함하고 있다. 입문서 범위내에서, 바른 길로 가도록 도와줄 마지막 연습을 보일 때가 왔다. 연습: 최초 탐색 이 강의를 위한 연습은 커피 한 잔을 준비하고, 웹 브라우저를 시동하고, 몇 가지 온라인 DocBook 자료를 확인하는 것이다.

• DocBook 링크 중 제일 좋은 모음은 Mark Johnson의 DocBookmarks 페이지이다. 페이지 상단에 링크된 몇 가지의 초보자용 입문서를 살펴 본다. 또한 아래에 있는 Nik Clayton의 FreeBSD documentation primer, Lauri Watts의 KDE DocBook handbook, Dava Mason등이 저술한 GNOME documentation handbook, 그리고 Markus Hoenicka의 epic SGML for NT tutorial과 같은 몇 가지 다른 링크도 살펴볼 필요가 있다.
• DocBook DTD의 공식 홈페이지인 OASIS(Organization for the Advancement of Structured Informaton Standards)의 DocBook 사이트도 둘러보아라. OASIS의 docbook과 docbook-apps의 메일링 리스트를 방문하고 구독신청 하는 것도 잊어서는 안 된다.
• 모듈형태의 DocBook 스타일시트를 관리하는 Norm Walsh의 DocBook 사이트에 들르는 것도 요구되며, 웹사이트를 제작하고 슬라이드 발표물을 만드는데 맞춰진 DocBook도 봐야 한다(Walsh는 『DocBook: The Definitive Guide』의 주요 저자이며 OASIS의 DocBook 기술 위원회의 회장직을 맡고 있는 DocBook의 여러 역할을 가지고 있다). Walsh는 몇몇 내용들을 DocBook 공개 저장소(다음 항목을 보라)로 이동하였음에도 불구하고 여전히 그의 사이트는 숙독할 필요가 있다. 여러분이 발견하게 될 내용에는 DocBook 소개 발표자료인 슬라이드 뿐만아니라 DocBook XSL 스타일시트 설계와 같은 기사들이 포함 될 것이다.
• 마지막으로 SourceForge에서 호스팅하고 있는 DocBook 공개 저장소¹⁶를 확인하라. 그 사이트에서 스타일 시트, 스키마, DTD들에 대한 개발 버전을 담고 있는 CVS 저장소를 일람할 수 있다. 또한 버그 리포트, 스타일시트 기능요구, DocBook DTD와 스키마에 대해 개선 요구를 보거나 제출할 수도 있음을 알게 될 것이다.

결론 저자인 Miachel Smith는 DocBook을 배우는데 가치 있다고 생각하는 문서의 저자들을 알리기 위한 것 뿐만 아니라 몇 가지 확장된 토론을 이끌어내기 위해 이 글을 썼다. 그러므로 여러분이 이 기사에 대해 논평할게 있다면 이 주제에 대해 좋은 토론을 할 수 있는 장소인 xml-doc 메일링 리스트에 주저말고 얘기해 주길 바란다.

---

Michael Smith는 Emily Dickinson Random Epigram Machine의 개발자이면서 DocBook 공개 저장소 개발팀과 DocBook 기술 위원회의 회원이며, xml-doc 메일링 리스트를 정리하고 있다. 2001년 8월에는 동경으로 영구 이주한다. 여러분은 smith@sideshowbarker.net로 메일을 보낼 수 있다.