Subscription Form
Contributors

날로 먹는것 같은 느낌이 들지만, 이런 리뷰들은 스크랩해서 읽어보면 나중에라도 큰재미, 큰도움을 줍니다. 저야 감사할따름이죠. ^. ^;

Elliotte Rusty Harold
, Adjunct Professor, Polytechnic University – 2008 년 2 월 04 일

Elliotte Rusty Harold가 2007년 한해 중요한 XML 뉴스를 되짚어 봅니다.

2007년은 XML에 있어서는 그 어느 때 보다도 느린 한 해였다. 하지만, 여러 중요한 스팩들이 1.0 버전을 발표했고, XML 출판물도 지속적인 관심을 받았다. 가장 중요한 것은, REST라는 빙산과 충돌한 웹 서비스라는 배는 난파가 되고, 바다 밑으로 가라 앉기 시작했다. 웹 서비스라는 타이타닉호를 가라앉게 만든 빙산의 꼭대기에는 POX가 있었는데, 이것은 스키마 또는 스팩 없이 표준 HTTP를 통해 보내지는 평범한 XML 문서이다. (어떤 사람들은 이미 수년 전에 빙산에 가까이 가고 있다는 것을 알았지만, Roy Fielding이 말했던 것처럼, “업계는 직접 이를 증명해 보이고 있다.”)

빙산의 표면 밑에 숨겨진 90%가 REST가 전부는 아니다. XML의 완전한 힘은 아직 탐사되지 않았다. Atom Publishing Protocol (APP)과 XQuery 모두 올해 1.0을 달성했고, 그 결과가 이제 막 나타나기 시작했다.

지난 10년 동안 왕 행세를 자처했던 수 많은 경쟁 상대(YAML, SML, S-expressions 등)들 속에서 살아남은 XML은 JSON의 인기 때문에 2007년에 가장 심각한 도전에 직면했다. JSON의 대중화는 절정에 이르지 않았지만, JSON의 한계, 보안 문제, 엉성하게 설계된 API에도 불구하고 내년에도 계속 증가할 전망이다.

1월

XQuery는 5년이 지난 지금까지도 “다음 해(를 기약하는)” 기술이었지만, 1월 XQuery 1.0의 공식 발표로 그 약속은 마침내 실현되었다. Mark Logic, eXist, Sedna, Berkeley DB XML을 포함하여, 여러 순수 XML 데이터베이스들이 이미 이것을 구현했다. 또한 IBM® DB2® 9과 Oracle 10g를 포함하고 있는 하이브리드 데이터베이스도 있다. XQuery 역시 Michael Kay의 Saxon과 DataDirect XQuery를 포함한 독립형 제품에서 사용할 수 있다.

하지만, 작업은 아직 끝나지 않았다. XQuery는 솔루션의 일부일 뿐이다. CRUD 관점에서, XQuery는 Create, Update, Delete가 없이 Read만 있을 뿐이다. 이러한 필수 기능들은 상용 확장으로 채워져야 한다. 다시 말해서, 한 구현에서 다른 구현으로 애플리케이션이나 데이터베이스를 쉽게 이동할 수 없다는 의미가 된다. 더 중요한 것은, 개발자들에게 표준 신택스를 가르칠 수 없고, DB2 9애플리케이션 작업을 수행할 수 있는 숙련된 Mark Logic 프로그래머를 쉽게 고용할 수 없다. (프로그램은 플랫폼들간 좀처럼 이동하지 않지만, 개발자들은 종종 그렇게 하고 있다.) XQuery는 업데이트(그리고 생성과 삭제) 장치가 필요하다. World Wide Web Consortium (W3C)은 8월 XQuery Update Facility 1.0을 발표했고, 벤더들은 이를 구현하기 시작했다. XML 커뮤니티가 운이 좋다면, 2008년에는 최종 릴리스를 만날 수도 있을 것이다.

XQuery 작업 그룹은 올해 첫 번째 XQuery 1.1 요구 사항을 발표했다. 중요한 신기능으로는 예외 핸들링, 확장 함수, 함수 포인터, lambda 식이 있다. 운이 좋다면, 완성되기 까지 5년에서 6년 정도 걸릴 것이다. XQuery 채택이 실제로 시작되고, 스팩 변경이 SQL, Fortran, C의 경우처럼 수십 년 걸리기 전에 지금 시작하는 것이 더 낫다.

비록, XQuery가 완전한 프로그래밍 언어이고, PHP, 정적 HTML, 기타 웹 프레임웍을 완벽히 대체할 수 있지만, 이것을 앞으로도 사용할 수 있으려면 기존 언어들로 작성된 프로그램들과 통합해야 한다. 따라서, XQuery API for Java (XQJ)가 올해 Java Community Process에 최종안을 제안했다는 것은 높이 살만한 일이다. 이것을 XQuery용 JDBC로 보면 된다. XQJ도 Saxon 9과 Data Direct XQuery 3.0으로 이미 지원되며, 내년 최종 스팩이 발표되면 더 많은 벤더들이 이를 따를 것이다.

2월

일년 중 가장 짧고 추운 달에, 모든 사람들은 집에 머물게 되고, 많은 일이 일어나지 않는다. Saxon, TagSoup, WebCGM 등의 신 버전 발표가 있었다. (정확히, WebCGM은 무엇인가?)

올해 XForms 1.1의 초안이 발표되었는데, PUT과 DELETE 제출 지원을 포함하여, 중요한 새로운 기능을 추가했다. 하지만, 올해 나머지 열 달은 XForms를 최종안으로 만들기에는 충분하지 않았다. 11월에 XForms 1.1이 나왔을 뿐이다. 아마도 내년에는 가능할 것으로 보인다.

가장 중요한 XForms 벤더들이 FormsPlayer, Chiba, Orbeon, Mozilla XForms 확장을 포함하여, 올해 업데이트 버전들을 릴리스 했다. 안타깝게도, 메이저 브라우저의 XForms 지원은 아직도 요원하다.

3월

W3C는 Internet Engineering Task Force (IETF) HTML 2.0 실패에 대한 직접적인 결과로 십 년 전에 만들어졌다. 이러한 역사적 배경에도 불구하고, 2006년에 W3C가 HTML을 포기했다는 것 사실은 놀라운 일이다. 2000년대부터, 이들은 XML과 Semantic Web에 너무 집중한 나머지 W3C의 설립 목표인 HTML을 잊어버렸다. 따라서, 2004년에, 일부 웹 디자이너와 브라우저 벤더들은 Web Hypertext Application Technology Working Group (WhatWG)으로 뭉쳤고 W3C가 떨어트린 공을 집어 들었다.

2년만인 3월에 W3C는 성과를 거둘 때가 되었다고 느꼈다. 자신들의 HTML 실무 그룹을 가동시키고, 격차 해소를 위해 움직이기 시작했다. 두 팀들이 동의했지만, WhatWG는 여전히 쿼터백 역할을 하고 있고, 독자적인 행동을 하고 있다.

이러한 소동에도 불구하고, HTML 5 코드가 2007년에 만들어졌다. 스팩 개발은 웹 비디오, SQL API, 파싱에 초점을 맞추었다. 일반인들이 사용하는 웹 브라우저에서 실행되는지 여부는 여전히 의문이다. 개인적으로, 필자는 네이티브 XML 데이터베이스가 준비 중일 당시에 인-브라우저 SQL API를 개발했을 당시의 지혜를 배우고 싶다. (풋볼 은유는 여기에서 그만두겠다. 필자가 계속 은유법을 쓰려고 하면 필자의 심판 호루라기를 가져가도 좋다.)

4월

XML이 웹에 의미(semantics)를 가져다 주고, 브라우저가 디스플레이 하고 있는 것이 무엇인지를 이해할 수 있다는 가설에도 불구하고, XML은 언제나 의미론이 아닌 신택스에 관한 것이었다. 전체적인 XML 1.0 스팩에는 두 개의 의미론적 애트리뷰트가 있다: xml:spacexml:lang (필자는 xml:space에 대해서는 잘 모르겠다.) 대부분의 경우, 의미는 문서 자체가 아니라 XML 문서를 처리하는 애플리케이션에서 발생한다. 이것은 네임스페이스, XML Infoset, XSLT, XPath의 뒤를 잇는 XML 군의 중요한 스팩이다.

하지만, 4월에 W3C는 Internationalization Tag Set (ITS) 1.0을 릴리스 함으로써 xml:lang 애트리뷰트를 확장했다. 이 권고안은 방향성, 번역 가능성, ruby 텍스트, 다른 많은 어휘들간 공유될 수 있는 문서 로컬화와 국제화의 공통적인 측면들을 구분하는 표준 애트리뷰트를 정의하고 있다. 예를 들어, Listing 1의 DocBook 아티클에서, its:translate 애트리뷰트는 필자 엘리먼트가 번역되어서는 안된다는 것을 나타내고 있고, its:dir 애트리뷰트는 전체 문서가 왼쪽에서 오른쪽으로 된 텍스트라는 것을 나타내고 있다.

Listing 1. 추가 ITS 마크업이 있는 DocBook

                 <xforms:model><dbk:article
      xmlns:its="http://www.w3.org/2005/11/its"
      xmlns:dbk="http://docbook.org/ns/docbook"
      its:version="1.0" version="5.0" xml:lang="en"
      its:dir="ltr">
  <dbk:info>
    <dbk:title>Fun with XML</dbk:title>
    <dbk:author its:translate="no">
       <dbk:personname>
         <dbk:firstname>Elliotte</dbk:firstname>
         <dbk:surname>Harold</dbk:surname>
       </dbk:personname>
     </dbk:author>
   </dbk:info>
   <dbk:para>XML rocks!</dbk:para>
</dbk:article>

이 스팩은 많은 주목을 끌지 못했지만, 다중 언어 환경에서 출판을 하는 사람들 (그리고, 요즘은 거의 모든 사람들)에게는 유용하다.

4월에, W3C Internationalization Activity 역시 최종 버전의 Internationalization Best Practices: Specifying Language in XHTML & HTML Content를 발표했다. 이 권고안은 16 개의 “베스트 프랙티스”로 요약될 수 있다:

  • 베스트 프랙티스 1: 문서에 한 개 이상의 언어를 말하는 사람을 위한 콘텐트를 포함하지 않는 한, html 태그에 애트리뷰트를 사용하여 페이지에 있는 텍스트용 기본 언어를 선언한다.
  • 베스트 프랙티스 2: 문서에 한 개 이상의 언어를 말하는 사람을 위한 콘텐트가 있을 경우, html 태그에 한 언어를 선언하거나 나중에 까지 정의되지 않은 채로 두라.
  • 베스트 프랙티스 3: 문서에 한 개 이상의 언어를 말하는 사람을 위한 콘텐트가 있을 경우, 문서를 언어 별로 구분하고, 각각에 알맞은 언어를 선언한다.
  • 베스트 프랙티스 4: 텍스트 주위에 lang 또는 xml:lang 애트리뷰트를 사용하여 언어의 변경 사항을 표시한다.
  • 베스트 프랙티스 5: HTML의 경우, lang 애트리뷰트만 사용하고, text/html로서 제공되는 XHTML 1.0의 경우, lang과 xml:lang 애트리뷰트를 사용하고, XML로서 제공되는 XHTML의 경우, xml:lang 애트리뷰트만 사용하라.
  • 베스트 프랙티스 6: HTTP 또는 메타 엘리먼트 보다는 언어 애트리뷰트를 사용하여 텍스트 프로세싱에 기본 언어를 선언하라.
  • 베스트 프랙티스 7: 바디 엘리먼트에 문서의 기본 언어를 선언하지 말고, html 엘리먼트를 사용하라.
  • 베스트 프랙티스 8: 애트리뷰트 값의 텍스트와 엘리먼트 콘텐트가 다른 언어로 되어 있다면, 중첩 방식을 사용해 보라.
  • 베스트 프랙티스 9: HTTP 헤더 또는 메타 태그에 Content-Language 선언을 사용하여 의도한 문서 사용자의 언어에 대한 메타데이터를 선언하라.
  • 베스트 프랙티스 10: 문서에 한 개 이상의 언어를 말하는 사람들을 위한 콘텐트가 있을 경우, Content-Language와 콤마 분리 리스트의 언어 태그를 사용하라.
  • 베스트 프랙티스 11: 언어 애트리뷰트 값에 대한 IETF의 BCP 47의 가이드라인을 따르라.
  • 베스트 프랙티스 12: 가능한 가장 짧은 언어 태그 값을 사용하라.
  • 베스트 프랙티스 13: 가능하다면, zh-Hans와 zh-Hant 코드를 사용하여 각각 Simplified 한자와 Traditional 한자를 언급하라.
  • 베스트 프랙티스 14: 또 다른 언어에 있는 리소스를 가리킬 때, 대상 문서의 언어를 표시하는 것의 장단점에 대해 생각해 보라.
  • 베스트 프랙티스 15: 한 엘리먼트의 대상 문서가 또 다른 언어로 되어있다는 것을 표시하고 싶다면, hreflang과 CSS를 사용해 보라.
  • 베스트 프랙티스 16: 언어를 표시하기 위해 플래그 아이콘을 사용하지 말라.

5월

MathML은 처음 XML을 응용한 것이었지만, 안타깝게도 이해하는데 한계가 있었다. 그럼에도 불구하고, W3C Math Working Group은 포기하지 않았고, 4월말에 MathML 3의 초안을 발표했다. (지금 5월을 이야기하는 것인 줄 알지만, 5월에는 XML 뉴스가 많지 않다.)

버전 3의 가장 중요한 기능은 초등학교 수학 표기법을 지원하는 것이다. MathML 3 역시 양방향 레이아웃에 대한 지원을 추가했고, 라인 브레이크와 향상된 조판을 위한 포지셔닝도 향상시켰다. 결국, 스팩은 다시 명확성을 중심으로 재작성 되었다. 세 번째 시도에서는 더욱 매력을 끄는 요소를 기대할 뿐이다. 결국, 수학은 웹이 발명된 이유가 된다.

6월

6월에, OpenOffice Project가 version 2.2를 발표했는데, 이것은 크로스 플랫폼 오피스 수트로서 국제화 표준 OpenDoc 포맷으로 압축된 XML로서 모든 파일들을 저장한다. 이것은 버그-픽스 릴리스이며, 높이 평가할 만 하다. 하지만, 진짜 뉴스는 OpenOffice Project도 네이티브 Mac OS X 버전과 리눅스®와 Microsoft® Windows®용 버전도 릴리스 했다는 점이다.

이전의 Mac에 대한 세미-릴리스와는 달리, 2.2는 X-Windows 보다는 Mac의 네이티브 Aqua 사용자 인터페이스 툴킷에 기반했다. Mac 릴리스는 최상의 품질이지만, OpenOffice를 Microsoft Office에 필적한 만한 것으로 만들기 위해서는 더욱 노력이 필요하다. OpenOffice가 많은 MacBook 프로그래머들을 매료시키려면, 1.0이후 고전을 면치 못했던 사용자 인터페이스 단점들을 해결해야 한다.

Apple이 Windows용 Safari 3.0 베타를 발표했다는 것이 6월의 가장 중대한 뉴스이다. 6%(또는 이상) 시장 점유율을 가진 콘텐트는 더 이상 없기 때문에, Apple은 Microsoft에 도전을 하는 것으로 보인다. 처음엔 iTunes이고 이제는 Safari인가? iLife와 iWork 보다 나은가? 2008년이 되면 승부가 가려질 것이다. 그 동안 Safari는 XML, XSLT, Cascading Style Sheets (CSS), XHTML, Atom, RSS를 지원해 왔다. Safari의 CSS 지원은 Windows의 브라우저들 보다 낫다. Google 강박증에서 벗어나는 동안, Microsoft는 Apple이 살금살금 다가오는 것을 눈치채지 못했을 것이다.

7월

7월에, W3C는 Efficient XML Interchange (EXI) Format 1.0 초안을 발표했다. 스팩을 정리하면:

“EXI는 성능과 전산 리소스의 활용을 동시에 최적화 할 수 있는 eXtensible Markup Language (XML) Information Set의 약자이다. EXI 포맷은 정보와 이전 언어 이론에서 차용한 하이브리드 방식을 사용하고, 입증된 실용적 기술을 사용했다. 빠르고 간결한 구현에 기여하는 비교적 단순한 알고리즘을 사용하고, 작은 데이터 유형 세트를 갖고 있으며, XML 이벤트 스트림을 효율적으로 인코딩 한다.”

나쁜 점에 대해서는 확신이 서지 않는다: 포맷의 모호함과 EXI가 XML infoset의 표현이 아니라는 사실이 단점으로 지적되고 있다. 모호함에 대해서는 필자도 예상했지만, 후자의 경우 필자도 예상하지 못했다. EXI는 Binary, Boolean, Decimal, Float, Integer, Unsigned Integer, Date-Time 같은 데이터 유형을 도입한다. XML은 데이터 유형이 없는데, 이는 버그가 아닌 하나의 특징이다. XML은 독자들에게 이것이 문서에서 찾은 텍스트의 특정 스트링을 해석하는 방법을 말해주지 않는다. 하지만 EXI는 한다.

다행히도, 올해 말까지 EXI는 Technical Architecture Group을 포함한 W3C의 그룹들에서 심각한 퇴출 위기를 겪고 있다. W3C 프로세스는 스팩을 없애는 과정이 어렵기 때문에, EXI는 결국 2008년에 릴리스 될 것이다. 이는 W3C가 만든 최초의 실패작도 아닐뿐더러, 마지막(스키마?)도 아니다; 하지만, 바이너리 직렬화에 있는 문제에 대한 충분한 사전 경고가 있어서 많은 피해는 입히지 않을 것이다. 세상 사람들이 XML Schemas 보다 XML 1.1을 더 좋아해주기를 기대해 본다.

8월

8월이 되면, XML 긱스는 Extreme Markup Languages 컨퍼런스가 열리는 몬트리올에 몰려든다. 세 개의 메이저 XML 쇼 중에 가장 특이한 쇼이다. 스타일시트나 스키마를 작성하는 방법에 대한 강의가 없다. 대신, 토픽에는 “A Web 2.0 ANSI SQL Transparent Native XML Nonlinear Hierarchical LCA Query Processor”과 “Exploring intertextual semantics: A reflection on attributes and optionality” 같은 부제가 포함된다.

이 컨퍼런스는 유료 참석자 보다는 강사에게 더 많은 재정적 부담이 있었다. 스폰서는 쇼가 끝날 때까지 컨퍼런스를 다시 개최할지 여부를 잘 결정하지 못하고, 모든 사람들은 한 해 더 열리기를 숨죽이며 기다린다. 슬프게도, 올해는 이러한 일이 일어나지 않았다. 2007년이 마지막 컨퍼런스가 될 것이다. (경쟁자들은 늘 넘쳐난다.)

하지만, 오래된 것이 사라지고 새로운 컨퍼런스가 등장하게 되었다. Mulberry Technologies Balisage를 발표했다: Markup Conference, 2008년 8월 12일부터 15일까지 몬트리올에서 개최된다.

“Balisage는 마크업 이론가와 실행가의 필요를 충족시키기 위해 고안되었다. 모든 것이 마크업에 관한 것이다: 마크업 생성 방법; 마크업의 의미; 계층과 오버랩; 모델링; 분류법; 변형; 쿼리, 검색; 프리젠테이션과 접근성; 마크업에 유리한 시스템 만들기(더 작은 공간에서는 다른 튜닝)-간단히 말해서, 마크업 정보의 힘을 통한 웹과 세상의 변화이다.”

2008년은 미국인은 비용 면의 효과가 없겠지만, 유럽과 캐나다 사람들은 비용 면에서 큰 혜택을 볼 것이다.

9월

올해의 가장 큰 사건은 9월에 일어났는데, 바로 Office Open XML 포맷의 지원에, Microsoft가 International Standards Organization (ISO)의 다양한 위원회들을 대상으로 선거전을 펼쳤다. 이 뉴스는 처음에 스웨덴을 강타했는데, 이곳에서 23개의 마이너 Microsoft 제휴 기업들이 Swedish Standards Institute에 참여했고, 이 중 22개 기업들이 OOXML을 승인하는 쪽으로 투표했다. 다른 표준 위원회 역시, Microsoft 파트너에서 그 어떤 해보다 회원으로서 역할에 만전을 기했다. 이전에 JTC 1/SC 34(특별한 ISO 소위원회로서 대부분의 XML 사건들이 이 곳에서 발생한다.)에 참여하지 않았던 나라들도 갑자기 참여했다.

비록, Office Open XML이 대다수의 표를 얻었지만(51-18-18), 최소한 “P-members”의 3분의 2 이상이거나, 반대표는 25% 미만이어야 했다. 두 부분을 만족시키지 못했기 때문에, 이 스팩은 해결을 위해 Ecma International로 보내졌다. 아마도 Microsoft는 스팩이 2월 재심의에서 필요한 여분의 표를 얻을 수 있을 정도로 충분히 향상시킬 수 있을 것이지만, 결과는 불확실 하다. 필자가 이 글을 쓰고 있는 현재, Microsoft는 OOXML의 혁명을 막을 수 있을 것 같지 않기 때문에, 이전의 Yes 표도 No 표로 바뀔 것이다.

OOXML 투표에 영향을 주려는 노력은 Document Schema Definition Languages (DSDL)을 포함한 다른 여러 무관한 스팩들에게도 치명적인 피해를 입혔다. OOXML에 찬성하여 투표했던 많은 새로운 멤버들은 다른 실무 그룹들의 태스크에는 관심이 없었다. 일단 표를 던져놓고 나서, 이 그룹이 무관하고, 논란거리도 되지 못하는 문제에 대해 정족수에 다다르지 못하게 만들어버렸다.

10월

10월에는 Atom Publishing Protocol이 릴리스 되었다. APP는 블로그 엔트리들을 업로딩하는 단순한 포맷으로 시작되어 MetaWeblog와 WordPress API 같은 커스텀 API를 대체하기 시작했다. 하지만, 결국 그 이상의 일을 하게 되었다.

APP는 콘텐트를 HTTP 서버에 공개하는 RESTful, 측정성, 확장성을 갖춘 보안 시스템이다. 한편으로는, 순수한 프로토콜이며, 특정 서버나 클라이언트와는 완전히 독립되어 있다. 또 한편, 이것은 단순한 HTTP이기 때문에, 기존 클라이언트와 서버에 구현하기가 쉽다.

웹(Web)은 원래 읽기-쓰기 미디어로 고안되었다. 하지만, 처음 15년 동안, 대부분의 에너지는 읽기 부분에 치중했다. 브라우저가 모든 관심의 초점이 되었지만, 작성 툴은 시들어갔다. 페이지 에디터는 빈약했고, FTP를 통해 파일 시스템으로 가야 했다. 지금 APP를 통해서, 브라우저로서 사용하기에 쉽고 풍부한 에디터의 새로운 장이 열렸다.

eXist 네이티브 XML 데이터베이스 같은 좋은 서버 소프트웨어는 이미 APP를 사용하기 시작했고, 여러 클라이언트들이 이것에 대한 작업을 하고 있다. 다가올 해에는 더 많은 작업이 진행될 것이다. 웹에 공개하는 것은 검색만큼이나 단순해질 것이다.

11월

11월에, Mark Logic은 이메일 압축 파일과 인터랙팅 하는 XQuery 기반 사이트인 MarkMail을 발표했다. 다음은 Jason Hunter의 설명이다:

“각 이메일은 XML 문서로서 내부에 저장되며, XQuery를 사용하여 액세스 된다. 모든 검색, 부분 검색, 분석 계산, HTML 페이지 렌더링이 하나의 MarkLogic Server 머신에서 수행된다.”

MarkMail은 현재 500개 이상의 Apache 메일링 리스트, jdom-interest, xml-dev를 기록하고 있다.

자연스럽게, 처음 사용자들은 모든 기능을 활용할 수 없었다. 이 컬렉션 안에서, Saxon의 Michael Kay는 언제나 1등 휴먼 포스터(commit 메시지를 보내는 일부 Apache 로봇이 이를 수행한다.)이긴 하지만, xml-dev에서, 탑 포스터의 영광은 4,000이상의 포스터를 가진 Len Bullard에게로 돌아갔다. Len의 포스트 대부분이 여러 페이지 아티클이란 사실은 이러한 사실을 더욱 강조한다.

필자는 1,014 포스트로 xml-dev에서 10위이다. 2년 전에 메일 클라이언트를 바꿨을 때, 스크린 이름이 “Elliotte Rusty Harold”에서 “Elliotte Harold”로 바뀌고, 데이터베이스가 두 명의 다른 사람으로 간주했을 때를 제외하고는 9위였다. 🙂

12월

12월은 올해의 가장 큰 XML 행사인 IDEAlliance의 연례 XML 2007 컨퍼런스로 시작되었다. 올해 이벤트는 보스톤에서 개최되었다. 참석자들의 수가 줄어서, 300명의 참석자와 15명의 전시자들로 구성되었다.

쇼 대부분이 이제는 비교적 잘 알려진 기술, 적어도 꾸준히 참석해온 XML 엘리트 개발자 그룹에는 친숙한 기술에 관한 것이었다. 작년과 마찬가지로, XForms도 두각을 나타냈지만, XQuery가 올해 행사의주인공이었다. XProc, RDFa, OpenDoc, Office Open XML, Atom, APP, JSON 역시 관심을 끌었던 주제였다. 웹 서비스와 SOAP과 관련된 것들이 빠지게 되어서 주목을 끌었다. “하지만 이제 우리는 REST로 옮겨가야 합니다.”라는 말 뒤에 등장한 것 빼고는 그러한 용어들을 들어본 적이 없었던 것으로 기억된다.

이 쇼에서 진정으로 새로운 것은 예기치 못한 소스에서 나왔는데, 다름아닌 Intel이었다. 하드웨어로 더 잘 알려진 Intel 역시 자사의 프로세서를 최대한 활용한 소프트웨어를 개발했다. Intel은 정말로 빠른 XSLT 프로세싱, XPath 계산, XML Schema Validation, Document Object Model (DOM)과 Simple API for XML (SAX) 파싱 을 제공하는 리눅스와 Windows용 X86 라이브러리의 컬렉션인 Intel XML Software Suite를 선보이기 위해 참여했다. 자바™ 플랫폼용 Java Native Interface (JNI) 기반 래퍼도 포함되었다.

Intel은 이 라이브러리가 XSLTC과, 그리고 XPath와 XSLT용 Xalan보다 두 배 빠르고, 대형 문서(100 megabyte 이상)의 파싱에 있어서 Xerces-C++ 보다 여섯 배 빠르다고 주장했다. 이 파서는 적은 메모리를 차지하는 심볼 테이블 데이터 구조를 사용하고, 두 개 이상의 코어에서 프로세싱을 멀티쓰레딩 함으로써 이를 달성했다. 문서는 300 MB에서 32 GB 영역으로 늘어났다. 더 작은 문서의 경우, 기술의 오버헤드가 전통적인 파서를 더욱 빠르게 한다.

필자는 이들이 주장하는 바를 테스트 하지는 못했지만, 이들의 말이 사실이라면, 매우 좋은 것이다. Xerces는 가장 빠른 파서는 아니지만, 여섯 배의 속도 향상은 어쨌든 좋은 것임에 틀림없다. 놀랍게도 Intel은 표준 API인 SAX와 DOM으로 이를 완성해냈다. 개인적으로, XML 파싱 성능이 향상될 것이라는 것임에는 의심의 여지가 없지만, 고성능을 위해 고안된 새로운 API가 필요하긴 하다.

12월은 일반적으로 W3C 그룹도 작업을 종료하고 크리스마스 휴일 전에 스팩을 발표한다. 크리스마스가 되기 바로 전 주가 일반적으로 W3C에게 있어서는 한 해 중 가장 바쁜 해이다. http://www.w3.org/TR/을 주시하기 바란다. 그러다 보면 놀랄만한 사실도 발견하게 될 것이다. 🙂

IBM DeveloperWorks

사용자 삽입 이미지필자소개 Elliotte Rusty Harold는 New Orleans 태생이다. 지금은 Brooklyn 근처 Prospect Heights에서 아내 Beth와 고양이 Charm 그리고 Marjorie와 함께 살고 있다. Polytechnic University의 조교수로서 자바와 객체 지향 프로그래밍을 강의하고 있다. 그의 Cafe au Lait 웹 사이트는 가장 인기 있는 자바 사이트가 되었고, Cafe con Leche는 가장 대중적인 XML사이트가 되었다. Effective XML, Processing XML with Java, Java Network Programming, Java I/O, 2nd edition)를 집필했다. 그는 현재 XML 프로세스용 XOM API, Jaxen XPath 엔진 Jester 테스트 툴 작업을 하고 있다.

 

Total
0
Shares

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다