마이크로포맷은 HTML/XHTML과 Atom 같은 호스트 포맷으로 더욱 풍부한 의미를 터널링하는 방식으로, 2년 전에 탄생했다. HTML은 연락처 정보를 표현할 수 있는 직접적인 방법은 없지만, hCard라고 하는 마이크로포맷은 단조로운 HTML divs와 spans를 변형하여 연락처 이름, 주소, 우편 번호 등을 지정할 수 있도록 해준다. 일부 마이크로포맷의 기본 개념은 건전하지만, 가끔씩 사람들은 마이크로포맷을 사용하는 이유와 시기를 오해하고 있다. 마이크로포맷은 웹에 풍부한 콘텐트를 표현하는데 사용할 수 있는 툴이어야 하고, 웹용 XML과 심지어 Ajax 같은 기술들을 대체하는 것이 아닌 보완해야 한다. 이 글에서는 마이크로포맷을 사용할 수 있는 적합한 때에 대해 설명한다.
마이크로포맷은 HTML, XHTML, Atom 같은 호스트 언어의 일반적인 구조에 약간의 뉘앙스(nuance)를 추가할 때 적합하다. 그 대표적인 예가 rel-license,인데, 소스 페이지의 콘텐트에 대한 사용 라이센스를 링크를 통해 표시할 수 있다. 페이지 어디에나 있는 <a href="http://creativecommons.org/licenses/by/2.0/" rel="license">cc by 2.0</a> 링크는 이 페이지의 콘텐트는 Creative Commons 2.0 Attribution Required 라이센스로 사용할 수 있다는 것을 의미한다. 필자는 사람들이 이 마이크로포맷을 남용하여 페이지 그 자체 보다는 페이지에 의해 기술된 소프트웨어에 대한 라이센스를 언급하는 것을 보았지만, 사람들은 이 문제에 대해 마이크로포맷의 개발자를 탓할 수 없다. 더 큰 문제는 이와 같은 계약이 충돌할 가능성이 있지만, 대부분의 경우, 마이크로포맷은 이 같은 문제들을 무시하면서, 가벼운 계약으로 이러한 문제들이 해결되기를 바라고 있다. rel-license는 이 같은 규약을 수행하도록 설계된 HTML 애트리뷰트의 사용 규약을 제공하고 있다. 단지 호스트 어휘의 구조 같은 뉘앙스만 제공할 뿐이고, 필자는 이러한 마이크로포맷을 뉘앙스 마이크로포맷(nuance microformats)이라고 부른다. 이들 대부분은 마이크로포맷 디자이너들이 기본 마이크로포맷이라고 하는 것으로서, 하나의 엘리먼트 안에 전체가 구현된다.
일부 마이크로포맷은 특화된 구조를 호스트 언어의 구조로 터널링을 시도한다. 필자는 이것을 불법(nuisance) 마이크로포맷이라고 부른다. 이 글에서는 마이크로포맷 디자이너들이 사용하는 보다 중립적인 표현인 복합 마이크로포맷(compound microformats.)이라는 표현을 사용하겠다. XOXO,가 대표적인 예이다. 이것은 아웃라인을 표현하는 마이크로포맷이다. XOXO는 훨씬 더 심오하고 거의 모든 XML 보다 처리하기가 더 어렵다. 물론, XML은 콘텐트에 대해 복잡하고 특화된 구조를 나타내도록 디자인 되었고, 구조를 HTML에 삽입한다는 이유 만으로 표현성이 떨어지는 것을 사용하는 것은 퇴보하는 것처럼 보인다. 마이크로포맷 사용자들은 XML이 너무 복잡하고, 더 중요한 것은 XML 같은 고급 기술을 이해하지 못하는 사용자 에이전트에게는 마이크로포맷이 일반 HTML처럼 여겨질 것이라고 생각하고 있다. 이는 매우 잘못된 생각이다. XML은 요즘 거의 모든 사용자 에이전트에 의해 지원되고, 가끔 웹용 확장성 디자인으로 그러한 불편함이 줄어들었기 때문이다. 다른 RSS들이 많이 있음에도 Atom은 더 나은 웹 피드 포맷으로서 개발되었다. Cascading Stylesheets (CSS)는 웹 페이지에서 콘텐트와 표현을 분리하는 방식으로서 개발되었다. 비록, CSS를 사용하려는 양심적인 웹 개발자들 앞에 놓인 장애물 브라우저와 관계 없이, 게으른 웹 퍼블리셔는 font와 center 태그를 사용하는 것이 더 쉽다. 과거의 유산이라는 무거운 짐에도 불구하고, 두 기술 모두 잘 작동하고 기존 기술은 마이크로포맷의 엉성한 디자인에 대한 궁색한 변명에 불과하다.
마이크로포맷의 대표적인 유스 케이스는 웹로깅(Weblogging)이다. 작성자가 엔트리들을 hAtom으로 마크업 하고, blogroll을 XOXO로, 라이센스를 rel-license로, 인라인(in-line) 연락처 정보를 hCard로 마크업 한다. 마이크로포맷은 Weblog 엔진 템플릿을 업데이트 함으로써 다소 구조화된 폼으로 모든 데이터를 퍼블리쉬 하는 간단한 방식을 제공한다. 또한, Weblog는 눈에 띄지 않게 강등되어 독자들이 마이크로포맷 인식 소프트웨어를 갖고 있지 않더라도 정보를 여전히 직접 읽을 수 있다.
이 모든 것은 합리적인 것처럼 들리지만, 웹의 기본적인 가치를 무시하는 것이다. HTML은 페이지로 구성되는 산문을 위한 것이다. 링크를 사용하여 페이지들을 연결할 수 있다. 이미지, 스타일시트 같은 객체에 대한 링크를 사용하여 비 산문적인 데이터를 나타낸다. 이는 오늘날 매우 잘 작동한다. XML 문서에 대한 링크에 의해 주소록, 웹 피드를 표현하지 않을 이유가 없다. XML은 반 구조화된 데이터를 위한 것이다. 가끔, XML은 이러한 데이터에 가장 적합한 포맷은 아니다. 고도록 구조화 된 데이터의 경우, JavaScript Object Notation (JSON)이 더 낫다. 그럼에도 불구하고, 각 기술은 목적에 맞게 사용하기 쉬우면서, 웹 브라우저, 모바일 브라우저와도 최대의 호환성을 유지한다.
Atom의 명백한 XML 대안인 hAtom으로 시작하겠다. 이미 XML 폼의 Atom도 있다. 이것은 잘 성장하고 있고 지원도 받고 있다. 정식 웹 페이지에서 Atom 피드로의 링크에 대한 규약도 있다.
<link rel="alternate" type="application/atom+xml" title="BobSutor's blog feed"
href="/developerworks/blogs/rss/BobSutor?flavor=atomdw" />
|
피드 링크를 추가하는 것은 hAtom의 다양한 명령을 따르는 것 보다 훨씬 쉽다. hAtom을 지원할 것 같은 Weblog 소프트웨어는 순수 Atom은 더욱 잘 지원할 것이다. 링크로 연결된 Atom 파일은 페이지만큼이나 정교하게 대부분의 검색 엔진에 의해 색인이 될 것이다. 검색 엔진 스파이더는 웹 피드 링크 규약을 통해서(그 자체로는 마이크로포맷의 폼으로 되어 있음) 링크로 연결된 Atom 파일을 인터프리팅 하는 방법을 알고 있다. 웹 툴과 서비스를 작성하는 용도로서 Atom은 hAtom보다 파싱 및 처리가 훨씬 더 쉽다. XML의 엄격한 신택스를 얻고 hAtom으로 작업하기 위해 두 개의 시맨틱 레이어 스택을 소비할 필요가 없다. hAtom은 불법 마이크로포맷이라기 보다는 뉘앙스 마이크로포맷에 더 가깝다는 사실에도 불구하고 올바른 XML Atom이라는 혜택도 누릴 수 있다.
관련 Weblog("blogroll")의 리스트에 대한 XOXO의 케이스로 옮겨가면, Atom의 경우에서처럼 명확한 XML 표준이 없다. blogroll은 엔트리의 인라인 콘텐트의 일부가 아니라, 전체 Weblog 템플릿 보일러플레이트의 일부이다. Listing 1은 XOXO Blogroll의 예제이다.
Listing 1. XOXO blogroll 예제
<ol class="xoxo">
<li>
<p>My favorite Weblogs</p>
<ol>
<li>
<a href="http://example.com/bud/" type="text/html">Buddy blog</a>
<a href="http://example.com/bud/atom" type="application/atom+xml">Buddy feed</a>
<dl>
<dt>description</dt>
<dd>My buddy's Weblog</dd>
</dl>
</li>
</ol>
</li>
</ol>
|
실제로, 어떻게 할 방법이 없다. XML 포맷이 네 개 또는 다섯 개의 엘리먼트(플레인 HTML의 경우 여섯 개의 엘리먼트)로 할 수 있었던 것을 10개의 엘리먼트가 사용되고 있다. Listing 1은 단순화 된 XOXO 예제이다. 필자는 훨씬 더 복잡한 예제도 보았다. 여기에서의 문제는 왜곡된 HTML에 있는 엘리먼트가 blogroll 의미를 표현하고, XOXO가 복잡성을 가져오고, 여기에 에러의 위험 부담이 늘어났다는 점이다. 그리고, 얻을 수 있는 혜택도 없다. Listing 2의 간단한 보일러플레이트를 사용할 수 있다.
Listing 2. 플레인 HTML blogroll 예제
<div class="blogroll">
<h3>My favorite Weblogs</h3>
<ol>
<li>
<a href="http://example.com/bud/" type="text/html">Buddy blog</a>
(<a href="http://example.com/bud/atom"
type="application/atom+xml">Buddy feed</a>): My buddy's Weblog
</li>
</div>
|
혼란이나 에러 없이 에뮬레이트 하기가 훨씬 더 쉽다.
XOXO (Listing 1)와 비교했을 때 플레인 HTML 예제(Listing 2)의 한 가지 단점은 blogroll이 머신 읽기를 위해 더 이상 구조화 되지 않는다는 점이다. 이를 수정하기 위해, 단순히 링크의 컬렉션인 구조화 된 blogroll 데이터에 대한 링크를 제공한다. 이 데이터는 매우 구조화 되어 있고, JSON을 포함하여, XML 외의 다른 데이터 포맷에 맞춰 수정할 수 있다. Listing 3은 blogroll용 JSON 예제이다.
Listing 3. JSON blogroll 데이터 예제
[
{"blog": "http://example.com/bud/",
"feed": "http://example.com/bud/atom",
"description": "My buddy's Weblog",
"tags": ["buddy"]
}
]
|
여러분은 이것을 간단한 파일로서 사용할 수 있고, Ajax 스크립팅 기술을 사용하여 링크 리스트에서 Listing 2의 플레인 HTML blogroll을 구현할 수 있다. 유연한 강등을 다루려면, Ajax 디자인에 맞는 적합한 기술을 선택하라. 대부분 IBM developerWorks에 소개되어 있다.
마이크로포맷이 자랑하는 커뮤니티는 마이크로포맷이 무리가 있을 때 이를 경고하는 역할을 해야 한다. Weblogger는 웹 기반 혁신의 핵심 동력이고 복합 마이크로포맷의 지독한 단점들을 줄일 수 있는 생각과 기술들을 끊임없이 도입해야 한다. 그러한 혁신을 이룩한다면, 이들을 에뮬레이트 하기 위해 소스 보기를 선택할 필요가 없다. Weblogger는 종종 자신의 기술을 채택하는 상세한 지침 사항을 게시한다. 확실히, 뉘앙스 마이크로포맷은 유용하고, 어느 정도의 동의와 실행 코드를 기반으로 구현된다. 이들은 MIME 유형, 파일 이름 확장용 공식 레지스터와 비슷하지만 중앙 컨트롤이 약하다. 마이크로포맷의 작성자가 이를 기반으로 구현하기 보다는 호스트 포맷을 왜곡할 때 문제가 생긴다. 이 같은 경우에 보다 적합한 포맷을 사용하는 것이 더 낫고, 웹은 건전한 선택을 도울 수 있는 유용한 수단이다.
교육
-
Microformats in Context: Uche Ogbuji.
-
JSON: 튜토리얼 및 스팩.
-
XML 입문 (한글): XML 기술의 기초를 다지고, developerWorks 관련 기술자료, 튜토리얼, 팁, IBM 교육 서비스, 웹 캐스트, 워크샵, IBM 제품들도 참조할 수 있다.
-
XML 표준
-
한국 developerWorks XML 존: XML 참고자료 찾기, Thinking XML의 이전 시리즈 보기와
Thinking XML 포럼에서 기술자료에 대한 의견을 게시할 수 있습니다.
-
IBM XML 인증
-
XML 기술 자료: developerWorks XML 존에서는 광범위한 기술자료, 팁, 튜토리얼, 표준, IBM Redbook을 제공하고 있습니다.
-
XML 기술 자료 (한글): developerWorks XML 존에서는 광범위한 기술자료, 팁, 튜토리얼, 표준, IBM Redbook을 제공하고 있습니다.
-
developerWorks 기술 이벤트와 웹 캐스트
제품 및 기술 얻기
-
Separate data and formatting with microformats (developerWorks, 2006년 7월): microformats, Jack D. Herrington.
-
IBM 시험판 SW: IBM 시험판 SW이용하여 다음 개발 프로젝트에 활용해보기 위한 developerWorks의 다운로드 페이지.
토론
