By 존 심슨(John E. Simpson), 역 한빛 리포터 1기 이상훈지난번 XML 워크샵에 가서 XML을 처음 정식으로 접했는데, IT업계에 종사하면서 한 번이라도 Dynamic Web을 개발해본 사람이면 HTML 코딩하는 게 얼마나 짜증나는 일인지 알 것이다. 비록 웹 디자이너와 같이 일을 하더라도 말이다. 그런데 XML은 이런 단점을 극복할 수 있는 해결책으로 보였다. 그래서 XML에 관심을 가지게 되었고, 그 쪽으로 자료를 찾아보던 중 XML(좀 더 정확히는 XHTML)에 관한 기사를 보게 되어 소개하고자 한다.
다음은 막 XML을 시작한 웹 개발자의 신경을 건드리는 두 가지 서로 관련된 질문과 이에 대한 답이다.
Q1: XML이 HTML을 대체할 것인가?A1: 철학적인 측면과 실용적인 측면의 두 가지로 답할 수 있겠다.
철학적인 측면에서 XML은 일시적인 경우가 아니라면, HTML의 대안으로서 실제적인 의미가 없다. XML 1.0 권고안(Recommendation)을 개발하고 있을 때, XML은 "웹을 위한 SGML" 또는 SGML 개념의 잔재라고 불리곤 했다. 사실 XML은 웹에 훌륭하게 적용된다. 그러나 수 많은 XML 기반의 마크업 언어를 구현하는 브라우저가 있지만(이미 많은 브라우저가 XML을 지원한다), 상응하는 문서 전부를 번역할 수 있는 이상적인 브라우저는 없다. 예를 들어, 종래의 브라우저는 는 말할 것도 없고 나 같은 태그는 해석할 수 없는 것이다.
그래서 좀 더 실용적인 측면의 답이 필요하다. 즉 이미 XML이 어느 정도 HTML을 대체하고 있다는 것이다.
독자는 World Wide Web Consortium(W3C)이 현재 4.01버전의 HTML 표준을 관리하고 있으며, W3C는 더 이상 HTML의 개정판을 발표하지 않을 것이라는 것을 알 것이다. 그 대신 확장 HTML 혹은 XHTML이라고 불리는 버전 1.0에 대한 권고안을 승인했다. 앞으로 웹의 표준어는 HTML이 아니라 XHTML이 될 것이다.
그러면 XHTML은 무엇인가? 간단히 말하면 XML화(化)한 HTML이다. 그래서 시작 태그는 끝 태그와 일치해야하고 모든 요소(element)는 서로에게 구조적으로 쌍을 이루어야 한다. 다음과 같이 구조를 중복하는 잘못된 구시대는 가버린 것이다.
This is bold and this is italic
but the italicized element doesn"t nest properly within
the bold.
A2에서 언급하겠지만, XHTML과 HTML 사이에는 중요한 차이점이 있다.
XHTML 1.0은 세 가지 "기호"를 제공한다( "기호"라는 말은 W3C의 용어라기에는 다소 기발하다).
XHTML 전환: 기존의 HTML 문서를 XHTML로 변경하고자할 때 사용하면 좋다. 엄밀히 말하자면, XML 문서에서는 내용 혹은 구조와 화면에 표시하는 방식을 엄격하게 구분해야 한다. 그래서 XML 문서에서는 와 같은 HTML 태그를 볼 수 없다. 진정한 XML 기반의 HTML에서 표시용 문자(배경색 속성과 같은)는 문서 자체와는 동 떨어진 스타일 시트로 나타내야 하는 것이다. XHTML 전환은 이런 요구에 유연하게 처리해서, 구식 브라우저(스타일시트 지원 여부와 상관없이)에서도 여전히 원하는 대로 동작할 것이다.
XHTML 엄격성: 이 부분은 유연성과는 거리가 멀다. 모든 표시 관련 마크업은 금지되며, 특정한 요소를 특정 방법으로 나타내고 싶으면 스타일 시트를 이용해야 한다.
XHTML 프레임세트: 웹 페이지를 프레임세트로 구성하려면 XHTML 1.0을 프레임세트로 쓰면 된다(각각의 프레임세트는 위의 두 가지 기호로 구현될 것이다).
Q2: HTML기반의 웹 문서를 XML로 바꿀 수 있는가?A2: 여기에서도 두 가지 대답이 가능하다. 첫째 대답은 단순히 XHTML만 이용할 경우이고, 둘째 대답은 HTML을 진정 의미 있는 MathML, Chemical Markup Language, 혹은 독자가 개발한 특정 애플리케이션에만 적용되는 마크업 언어로 바꾸려 할 경우의 대답이다.
먼저 HTML을 XHTML로 바꾸는 것을 살펴보자. W3C의 XHTML 권고안은 두 언어의 차이를 잘 나타낸다. A1에서 언급한 분명한 차이점 외에도 HTML 개발자를 놀라게 할 차이점이 더 있다. 한 예로, XML 요소는 대소문자를 구분한다. 가상의 HTML을 XML화(化)한 형태에서 태그는 와 와는 다른 요소를 나타난다. 따라서 개발자는 XHTML 권고대로 요소명(element name)을 모두 소문자로 쓰면 되는 것이다. 또한 HTML에서 , , , 와 같이 나타나는 빈요소 태그()는 태그를 닫기(>) 전에 슬래시(/)를 사용하는 XML 빈-요소 태그형태를 써야 된다. 은 로 은 로 바뀐다.
(주: XML을 이해하지 못하는 브라우저에서는 이러한 빈요소 형태가 지장을 초래한다. 하지만 대신에 을, 대신에 을 쓰는 것처럼 슬래시 앞에 공백을 주면 문제가 해결된다는 점을 위안으로 삼자. 필자의 생각으로는 브라우저 제공업체에서 마크업의 발전을 지연시켰다는 사실이 오히려 좋은 점으로 바뀐 것 같다. 게다가 이러한 특성으로 독자적인 역호환성을 갖는 XHTML을 작성할 수도 있는 것이다.)
현재 기존의 HTML을 가장 간단하게 변경하는 방법은 W3C 사이트의 Dave Raggett의 free HTML Tidy 유틸리티를 사용하는 것이다. Tidy는 광범위한 플랫폼에서 프로세싱을 지시하는 방대한 명령행 변수 배열을 입력받아서 처리하는데, 다수의 브라우저 제공업체와 개발자가 Tidy를 결합해서 제품을 만들고 있다 (윈도우 기반 플랫폼에서는 Chami.com의 free HTML-Kit 등이 인기 있다).
그러나 성가신 문제가 있다. HTML을 XHTML이 아니라, 진정한 XML 애플리케이션으로 바꾸려면 어떻게 해야 하는가?
이것이 성가신 이유는 HTML 요소명은 아무런 내재적인 뜻이 없는 반면(이 점에서는 XHTML도 마찬가지다), 모든 XML 애플리케이션은 직관적인 뜻이 있다.
다음과 같은 (X)HTML 부분을 살펴보자:
Charles Darwin
Origin of Species
Joseph Heller
Catch-22
XML 애플리케이션으로 변경하면 다음과 같다.
Charles DarwinOrigin of SpeciesJoseph HellerCatch-22
이는 매우 직관적이다. 그러나 일반적인 찾고-바꾸기 작업으로 변경하려고 하면, 모든
태그는 로,
은 으로,
내의 첫째
는 로 둘째
는 로 바꾸어야 한다. 만만하지 않은 작업이다(table의 줄이 3개나 그 이상의
요소를 가질 수도 있고, 단순한 스키마로서는 대응이 불가능한 경우도 있다).
주의 깊게 마크업한 HTML이라면, 특히 모든 요소 형태 내 각각의 인스턴스(instance)에 클래스 속성을 사용했다면(CSS를 쓰는 것과 같은), 이는 잘 작동할 것이다. 다음을 보자.
Charles Darwin
Origin of Species
Joseph Heller
Catch-22
이 경우에는 찾고 바꾸기(search-and-replace) 작업을 쉽게 할 수 있다. 어쨌든 시작 태그만 교정한다(물론 예상대로 처음에 이러한 클래스 속성을 모두 첨가하는 것은 충분히 짜증나는 일이다).
그래도 여전히 까다로운 수작업 변경과 문서의 구조를 파악하고 의미 있는 마크업으로 대칭시키는 매우 짜증나는 작업을 감수해야 한다. 개발자의 입장에서 보면, 수 년 내 이런 작업을 하지 않게 되기를 바랄 뿐이다. 그러나 이런 식으로 HTML을 XML로 바꾸게 될 가능성이 있다는 점이 문제다.
이상훈님은 한빛 리포터 1기로 활동 중이며, IDE Korea라는 컨설팅 + 개발 업체에서 인터넷 개발 쪽을 맡고 있습니다.