한빛출판네트워크

제공 : 한빛 네트워크
저자 : Micah Dubinko
역자 : 추홍엽
원문 : Is XML 2.0 Under Development?

한가지 인정해야만 할 것은, XML은 꽤나 성공적이었다는 것이다. 본 컬럼에서 언급할 충분한 양의 골칫거리들에도 불구하고 XML은 거의 모든 곳에서 동력원이 되고 있다. 웹을 제외한 거의 모든 곳에서. 만약 최근에 들리는 소문들이 징후라면 말이다.

Douglas Crockford가 XML 2006 컨퍼런스에서 했던 말들을 요약해보면, 웹상의 XML은 죽었다라는 수많은 선언의 목소리들에 대해 언급하고 있다. 일부는 이를 받아들이고, 일부는 XML이 그들 전부를 지배하는 유일한 메타언어라고 주장하며, 또 일부는 "XML은 아직 서버상에서의 역할을 가지고 있다. XML이 죽었다는 말을 방치해두면 사람들은 더 나은 대안책을 찾기 시작할 것이다."라고 말한다. 웹상에서 XML이 죽었다고 선언된 것은 이번이 처음이 아니다: 2004년으로 거슬러 올라가보면, Mark Pilgrim도 비슷한 선포를 했었다.

그러나 이러한 선언들에서 무시된 한가지 요소는 모바일 중심의 웹이다. 모바일 중심의 웹에서는 XHTML의 다양한 모듈화 기반의 변형들이 조용히 그 원래 전제에 맞게 움직여왔다. 각각의 브라우저는 구현의 질에서 아주 다양하지만, 엄격한 정형성과 뚜렷한 레이어링(그래, document.write 널 말하고 있는거다.) 및 웹 이상의 직관적인 사용성등의 핵심 개념을 포함한 언어 그자체는 모바일에서는 살아있고 건재하다. 그러한 환경에서 XHTML은 WML의 잔재를 넘어선 안정된 진보와 진행을 계속하고 있다.

그러나, 모바일의 세계 밖에서는 상황이 달라보인다. XHTML이 일반적인 웹상에서 HTML을 뛰어넘고 있다고 말하는 것은 다소 과장된 표현일 수 있다. 왜 틀릴까? 한가지 가능한 대답은 모바일이 얼리어댑터들에게 더 알맞다는 것이다: XML로 부터 타고난 이점들이 모바일에서는 본전을 뽑을 만한 가치를 제공한다. 모바일의 외부에 있는 사람들은 좀더 느릿한 태도를 취하지만, 결국 그들은 분명히 더 나은 방법을 찾아나설 것이며, 자바스크립트는 엄격한 문법을 가지고 그에 맞지 않게 되면 상대적으로 가혹한 결과를 가져다 주며, 이 모든 것들이 Ajax나 이와 유사한 클라이언트쪽 개발을 늦추지는 않았다.  

웹의 모바일 쪽이 왜 그 나머지들보다 XHTML로 빨리 옮겨갔는지를 생각해보는 것은 흥미롭다. 이 기사의 끝에 독자들의 댓글을 환영한다. 그러나 아직 두번째 질문이 남아있다: 자바스크립트의 수용이 정형성을 포함한 "엄격한" 에러 핸들링 지지자들의 승리를 의미하는가? 필자는 그렇게 생각하지 않는다. 불량한 페이지를 작성하는 방법은 많다, 그러나 적당히 만든 페이지는 스크립트 에러 이벤트를 얼마정도 수용하며 그 기능을 계속 할 것이다. (혹은 스크립트를 꺼놓은 브라우저의 경우에도 유사하다.) 재앙적인 자바스크립트 에러를 가진 웹페이지는 여전히 에러메시지가 아니고 웹페이지다. 실제로 그동안 브라우저 제조사들은 스크립트 에러들을 숨겨진 에러 콘솔로 밀어넣으며 점점 더 안보이게 만들어 왔다.

그러므로 스크립팅은 엄격한 처리--페이지는 정형성을 지키던지 그렇지 않으면 에러메시지를 내는--와 혼란스런 태그들 모음의 흥미로운 중간점을 차지한다. 효과적으로, 단순히 치명적 에러로써 다양한 조건들을 달아놓는 대신에, 그리고 인터프리터 구현끼리 충돌하는 것에 대해 모든 것을 자유롭게 열어두는 대신에, 마크업+스크립트의 조합은 피할 수 없는 에러들에 직면하여 계속 진행을 시도하는 처리모델을 정의한다. 이것이 웹상에서 훨씬 더 낫게 작동하는 것이 밝혀졌다. 웹에서의 XML이 죽었다고 말하는 대신 웹에서의 정형성이 죽었다고 말하는 것이 더 정확할 듯 하다. (다시 말하지만, 모바일은 예외다.)

이것은 다시 SGML 간소화 2.0에 대해 논의하게 만든다. XML에 대해 생각할 수 있는 방법은 많이 있다. 그러나 역사적인 기호상 그것은 SGML의 유도--원래 생각처럼 간소화--이다. 그러나 XML이 작성되기 전에 조차 SGML의 간소화된 일부의 씨앗이 HTML로 알려진 침체된 언어에서 벌써 뿌려졌었다. 예를 들어 HTML 2.0은 "HTML 도큐먼트는 광범위한 영역에서 정보를 표현하기에 적당한 일반적인 의미론을 가진 SGML 도큐먼트이다"라고 주장한다. 실제로 널리 사용되는 브라우저들은 SGML 파서를 통해 HTML을 처리한적이 없다. 다만 몇몇 온라인상의 유효성처리기들이 그렇게 처리했고 아마 계속 혼란속에서 그렇게 처리할 것이다. 아니, 실제로 모든 널리 쓰이는 브라우저들은 각기 자신만의 곤혹스러운 파서들을 가지고 있다. 이것은 XML도 SGML도 아니며 덜 세련되고 낡아빠졌다.

브라우저 제조사들은 이러한 쿼크방식의 파싱기술을 각기 디자인하고 구현하고 있었다. 그리고 XML의 디자인과 구현에도 분리되어 있었다. (간략하게 되짚어보면, HTML의 첫번째 드래프트가 1993년에 나왔고, 넷스케이프 네비이게이터의 첫번째 베타버전이 1994년에, HTML 2.0은 1995년, XML의 첫번째 작성된 드래프트가 1996년, 그리고 XML 1.0이 브라우저 전쟁의 열기속에서 1998년 초에 나왔다.) 그 결과 그 둘은 결코 만나지 못했다. 특히 브라우저 벤더들은 마법과도 같은 소스보기를 통해 서로의 미심쩍은 습관들을 빠르게 복사해가는 체계없는 작자들의 어리석고, 모순되고, 비생산적인 방법들에 특히 주의를 기울였다. 이와 대조적으로 XML은 너저분한 관례에 대항하고 더욱 엄격한 규칙을 준수하며 웹상에 존재하고 있는 실제들에 더욱 멀어지며 달려왔다.

매우 흥미롭게도 Tim Bray의 눈에서 XML 1.0이 빛나기 전부터 XML 2.0의 씨앗은 뿌려지고, 물이 주어지고, 싹이 트고 있었다. 컬럼에서 앞서 언급했듯이, Tim Berners-Lee는 브라우저벤더들과 관련 모임들만 가입된 WHAT WG에 크게 영향 받아, HTML 작업에 대한 재시작을 블로그에 올렸다. 이는 너저분한 문형에 대한 토의를 포함할 것이다. 효과적으로 이것은 SGML 규칙을 간략화하는 시도의 두번째 버전이고, 이를 "HTML5"처럼 비공식적인 명명 안과 똑같이 XML2라 부른다.

이러한 중요한 점은 반복을 포함한다: 그것이 궁극적으로 어떻게 불려지던간에 XML2는 이미 개발중에 있고 언젠가 등장할 것이며, 공식적인 W3C 권고안이 되기위한 길을 가고 있다는 것이다.

웹의 규모로 함축시키려는 이러한 노력은 상대적으로 거의 주목을 받지 못해왔다. 부분적으로는 이것이 XML의 경우처럼 문법에 대한 스펙이 따로 분리된 문서가 아니고 광범위한 스펙의 하나의 섹션으로 합쳐져 있기 때문이다. 이것은 몇몇 흥미로운 문제를 야기시킨다.

웹상에서 HTML은 특별한 케이스인가? HTML과 다른 것들에 대해 사용된 단일의 다목적 문형을 갖는 것이 가능할까? 혹은 또다른 방법으로, 하나의 언어에게 웹상에 현재 존재하는 실재들과 호환이 되는 그무엇의 방법으로 HTML 의미론을 표현할 수 있는 능력을 주어, 그언어가 퍼블리싱이나 컨텐츠 관리, 정보교환과 같은 다른 컨텍스트에서 유용하게 만들 수 있을까? 만약 대답이 "예"라면 웹은 분리된 독립 스펙으로 구체화된 XML2로 잘 수행되어질 것이다. XML이 XHTML의 일부로 최초로 지정될 수 있을지 상상해보라. 얼마다 달성될 수 있을까. 잘 디자인된 기술의 보증서는 그 창시자가 생각치 않았던 방법으로 사용되어지는가이다. 이것은 XML2를 작업하고 있는 그룹이 너무 좁은 배경에서 나오지 않는다면 일어날 것 같지 않다. 다행히 사람들은 눈치채고 있다. 예를 들어, Sam Ruby는 자신이 문형 설명들을 반영했었고 그 결과로 XML과 XML2와의 일시적인 비호환성이 없어지고 있다고 블로깅 해왔다.

TimBL의 블로그에 따르면 새로운 워킹그룹은 HTML과 XHTML 트랙을 따라 평행하게 개발하는 것을 추구할 것이다. 이는 더욱 마찰을 빚게될 것이다. 새로운 SGML 간소화 작업자들에게 단호하게 거부당할 한가지는 앞서 논의했듯이 네임스페이스 처리다. 이 시점에서 이것이 얼마나 걸릴지는 알기 힘들다. 예를 들어, HTML로 SVG(이것은 XLink를 임베드함)를 임베드 하려는 시도에서 어떤 문제들이 일어날 것인가? 전체 XML 툴셋이 HTML 사용에 대해 갈라질 필요가 있을까? XML 스키마나 XQuery와 같은 네임스페이스 중심의 기술들에 대해서는 어떤가? 이 워킹그룹은 더 진행하기 힘든 몇가지 결정사항들을 가지고 있다.

필자가 이 글을 쓸때 새 HTML에 대한 특권자들은 W3C 회원 고유의 영역에서 작업중이었다. 만약 여러분이 W3C 회원 조직과 관련되어 있고 XML에 대해 신경쓰고 있다면 지금이 자신의 의견을 알리기 가장 좋은 때다. 지금 의견을 말하던지 아니면 영원히 그 골칫거리를 가지고 가던지 하라. 아니면 적어도 XML3까지.