XML Matters: Ajax: XML의 다양한 대안들 (한글)

애플리케이션에 맞게 데이터를 인코딩(encode) 하는 가장 올바른 방법

JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.  난이도 : 중급 Dethe Elza, Senior Software Developer, Uniserve Communications Corporation David Mertz, Ph.D, Author, Gnosis Software, Inc. 2007 년 2 월 06 일 Ajax(Asynchronous JavaScript and XML)는 신뢰성을 기반으로, 서버에 채널을 개방하여, 웹 애플리케이션에서 사용되는 데이터를 교환하는 신개념 웹 브라우저입니다. 이것은 표준 웹 기술과는 반대되는 개념이고, Ajax를 기반으로 개발 할 때, 전통적인 웹 페이지들과는 다른 디자인 정책이 필요합니다. 백(back) 버튼을 관리하는 방법, 업데이트 된 데이터를 디스플레이 하는 방법, 업데이트를 보내는 빈도수 등도 그 예가 될 수 있습니다. 이 글에서는 데이터 교환에 어떤 포맷을 사용해야 할 것인지를 중점적으로 설명합니다. Ajax라는 단어에서 X는 XML을 뜻하지만, XML은 언어가 아니라 언어를 구현하는 툴킷이다. 따라서, 가장 먼저, 기존 언어를 사용할 것인가, 아니면 자신의 언어로 재 구축할 것인지를 결정해야 한다. 결정하고 나서는 부가적인 문제들이 생기기 시작한다. 기존의 언어들은 자신의 필요에 맞는가, 자신에 필요에 맞게 설계할 수 있는가? 그 언어를 처리할 툴은 있는가, 툴을 구현해야 하는가? 다른 사람들과 커뮤니케이션을 해야 한다면, 그 언어는 잘 알려진 언어인가? 다른 애플리케이션들도 쉽게 여러분의 데이터에 액세스 하여, 사용할 수 있는가? 그래픽 데이터일 경우에는 (X)HTML, SVG 또는 X3D, 데이터 조각에는 Atom, 단순한 아웃라인에는 OPML, 그래프에는 RDF 등 용도가 확실한 것도 있다. 완벽한 기능을 갖추고 있고, 장황한 DocBook, DITA, OpenOffice 포맷으로 된 데이터를 보낼 수도 있다. (참고자료) 한편, Ajax라는 단어에서 X가 무엇을 뜻하는지에 상관없이, 여러분이 원하는 다양한 종류의 데이터를 보낼 수 있다. 바이너리 데이터, 이미지, 무비, PDF 파일도 가능하지만, JavaScript로 되어있는 브라우저에서는 다루기 어렵다. XML 보다 단순한 텍스트 포맷으로 보낼 수도 있다. Tab 또는 콤마 분리 리스트(tab-, comma-delimited list), Markdown, YAML, JSON 등을 XML 대안으로 사용할 수 있다. 이외에도, XML을 사용하지 않는 수 십 개의 옵션들이 있다. (참고자료 - XML Alternatives 웹 사이트 참조) 물론, 장황함(verbose)과 풍부함(rich)의 차이는 있다. 심지어, 이 리스트에 있는 한 개의 아이템에서도 여러 가지의 데이터 인코딩 방식이 있을 수 있다. OpenOffice Spreadsheet DITA (Darwin Information Typing Architecture) DocBook RDF-XML XHTML Microformat Atom OPML (Outline Processor Markup Language) Custom XML Markdown / Textile / reStructured Text YAML (YAML Ain't Markup Language) JSON (JavaScript Object Notation) Comma- (or Tab-) delimited text 무엇을 선택하여야 하는가? 이러한 많은 옵션들 중에서, 어떻게 하면 현명한 결정을 내릴 수 있을까? 위에 제시한 리스트는 엄밀히 말해서 복잡한 순서대로 나열한 것은 아니다. 우선, 가장 단순한 방식 또는 가장 복잡한 방식으로 포맷을 사용할 수 있다. 생성, 읽기, 파싱, 프로세스 중에서 어떤 것이 가장 복잡한 것인지를 파악해야 한다. 예를 들어, XML은 그 자체로 복잡한 편이지만, 파서가 브라우저에 이미 있기 때문에 파싱은 오히려 단순하다. 복잡성은 데이터의 유형에 상당히 많이 의존한다. 스프레드시트나 데이터베이스처럼, 고정된 구조를 갖고 있는가? 워드 프로세싱 문서나 블로그 포스트처럼 유연한(loosely) 구조를 갖고 있는가? 항공기 매뉴얼 같은 대형 문서인가, 응답 코드 같은 작은 데이터 조각인가? 데이터 세트가 크다면, 이것을 한 번에 보낼 것인가, 아니면 필요할 때마다 작은 조각 단위로 보낼 것인가? 큰 데이터를 작은 조각 단위로 나누는 것은 얼마나 어려우며, 받는 쪽에서, 작은 조각들을 올바르게 조합하려면 얼마나 많은 정보가 필요한가? 즉, 무엇이 가장 중요한 요소인가? 장황함/대역폭(특별한 경우를 제외하고는, 이러한 요소는 여러분이 생각하는 것만큼 중요하지 않다.) 가독성(작성 가능성, 관리성) 파싱 난이도(클라이언트 측과 서버 측) 파싱 속도(네이티브 대 스크립팅) 정보 손실(ordered pairs -> dictionary -> sets) 유연성(가끔은, 덜 유연한 것이 더 나을 때도 있다.) 언어 이식성(얼마나 많은 언어들을 사용할 수 있는가?) 정확성(포맷에 어느 정도 순응하는가?) 라운드 트리핑 (Round-Tripping) (Markdown -> XHTML -> Markdown, 얼마나 많은 데이터 손실이 있는가?) 속도, 대역폭 활용, 효율성을 위해서가 아니라, 사용자를 만족시키기 위해 최적화 하는 경우가 대부분이다. 지연되는 부분은 숨기고, 즉각적인 업데이트가 가능하다면, 미미한 네트워크 지연은 문제가 되지 않는다. 바로 이것이 Ajax의 가장 큰 장점일 것이다. 위로 제 1 원칙 이 글에서, 몇 가지 선택 원칙을 제시하고, 이를 뒷받침 할 몇 가지 예제도 소개하겠다. 이모든 것들이 여러 가지 옵션들을 선택하는데 있어서 충실한 가이드라인이 될 것이다. 데이터용 JSON: 데이터가 구축되었다면 JSON이 제격이다. 적어도 세 개의 파서들이 브라우저에 포함되어 있고(HTML, XML, JavaScript), 이중 가장 빠른 것은 JavaScript 이다. 또한, 데이터가 이미 JavaScript로 되어 있을 경우, JavaScript를 사용하여 데이터를 조작하는 것이 DOM 보다는 낫다. 데이터를 바로 디스플레이 하지 않거나, 데이터가 먼저 수정되어야 한다거나, 또는 데이터가 웹 페이지의 다른 부분에서, 또는 다른 포맷으로 디스플레이 된다면, JSON이 잘 맞는다. 대부분의 언어들에는 JSON용 라이브러리가 있기 때문에, 더 이상 JavaScript만을 위한 것은 아니다. 혼합 콘텐트(문서)를 위한 XML: URL과 같은 메타데이터를 사용하거나, 워드 프로세싱 문서와 블로그 포스트 같은 마크업과 텍스트를 혼합해야 한다면 XML을 사용하라. 데이터가 한 곳에서 직접 디스플레이 된다면, 서버에서 이를 정형화(format)하고, Ajax를 사용하여 검색 및 삽입한다.(이 기법은 'client-side includes'라고 알려졌다.) David가 "MochiKit" (참고자료)에서 언급하였듯이, XML을 브라우저로 전달하고 CSS로 포맷하거나, 또는 HTML을 통해서 이를 스타일링 할 것인지를 선택할 수 있다. 당신이 XML을 사용해야 한다면, 필자는 XHTML, SVG, X3D등과 같은 표준 포맷을 사용하라는 것 외에 많은 가이드라인을 줄 수는 없다. 이러한 포맷들의 서브셋을 사용하여, 시스템들 간 상호 운용성이 뛰어난 데이터를 만들 수 있고, 다른 프로그래머들도 익숙하게 사용할 수 있도록 한다. 가끔은 자신만의 XML 포맷을 만들 수도 있지만, 상호 운용성 부분에서는 더욱 많은 신경을 써야 한다. 그것도 의심스럽다면, HTML을 계속 사용하라. 동기화(Syndication)를 위한 Atom: 여기에서 나는 동기화에 대해 매우 포괄적으로 정의를 내리고자 한다. 데이터를 주기적으로 업데이트 할 것이라면, 데이터에 타임스탬프가 필요하다면, Atom을 사용하는 것이 좋다. 또한, 데이터 흐름에 대한 표준 인벨롭(envelope)으로서 Atom 포맷을 사용하는 것이 좋다. 이렇게 하면, 애그리게이터(aggregator), 뉴스 리더기, 스크립팅 라이브러리를 통해서, 데이터를 추적하고 재사용할 수 있는 많은 툴들을 사용할 수 있을 것이다. 또한, 웹 페이지에 데이터를 삽입만 하면, 크게 노력하지 않아도 동기화 피드가 될 수 있는 효과도 누릴 수 있다. 위로 선택의 파라독스 이제, 다른 포맷들과, 각 포맷의 사용 방법에 대해서 알아보자. 이전 두 개의 칼럼에서는(참고자료) 메커니즘에 초점을 맞추느라 간단한 예제를 사용했지만, 이번에는 실제 예제를 사용해보겠다. 나의 아내인 Daniela는 시인이다. 그녀는 잡지, 콘테스트, 이벤트에 제출한 작품들을 관리해야 했다. 제출한 시가 어떤 단계에 와 있으며, 어떤 것이 채택 또는 탈락 되었는지, 각 작품당 가격은 얼마인지, 이벤트 비용은 얼마인지를 알아야 한다. Listing 1은 데이터 내용이다. Listing 1 Room of One's Own Submitted May 10, '05 * Hyacinth Blue * Fabrication * Thanksgiving * Spilling the Peas Accepted Hyacinth Blue Accepted Sept 2005 Published Oct 2006 Paid Sept 2006 Paid $50 + 2 copies Postage $1.12 Submission Fee: 0 Journal submission Surrey International Writer's Contest Contest submission Submitted Aug. 31 2006 * 13th Child Fee: $15 Postage: 1.05 Honorable Mention Prize: $150 + copy of anthology Accepted Sept. 26 2006 Publication Date Oct. 20 2006 Word on the Street Public Reading Invited speaker Reading time: 10 minutes Paid: T-shirt and lunch Date: Sept 24 2006 Paideusis: The Journal of the Canadian Philosophy of \ Education Society Submitted Oct. 13th 2006 * To carry over: metaphor invents us (seven poems) Email submission Referreed Journal Accepted Oct. 16th 2006 Published (Pending) Nov. 2006 어느 정도 까지는 이러한 포맷도 유효했지만, 출품작이 많아지면서, 트래킹(tracking)은 더욱 어려워졌다. 연간 수입과 지출을 가늠하기가 더 어려워졌고, 평균 응답 시간(제출과 채택 또는 탈락까지 걸리는 시간)같은 정보도 받아보고 싶었다. 그래서, 나는 아내에게 "Fame Not Fortune"이라고 하는, Ajax 웹 애플리케이션을 구현 할 것을 제안했다. 물론, 나의 게으름 탓에, 새로운 애플리케이션을 구현하지 않고, 원래 있었던 애플리케이션을 사용하게 되었다. 아내가 시를 편집할 때 Open Office (워드 프로세싱) (참고자료)를 사용하기 때문에, 그림1처럼 트래킹에도 Open Office (spreadsheet)를 사용할 수 있었다. 그림 1. Open Office Spreadsheet 예제 벌써, 몇 가지 문제가 드러나고 있다. 특히, 스프레드시트는 트래킹에 맞는 인터페이스가 아니다. 대상 데이터는 매우 유연하기 때문에, 많은 칼럼들이 채워지지 않았고, 아내도 스프레드시트를 사용하는 것에 익숙하지 않았다. 웹 애플리케이션을 구현해야 한다는 나의 생각이 옳았다. 물론, Open Office는 문서를 XML로 저장하기 때문에, 복잡한 데이터 마이닝(data-mining) 태스크에는 Open Office를 사용하고, 데이터 입력에는 웹을 사용하는 상황이다. 이러한 경우에는 한 가지 포맷을 결정하는 것이 더 낫다. Open Office에 저장된 포맷은, 실상은 데이터와 기타 리소스들(삽입된 이미지, 스크립트, 스타일링 정보)을 포함하고 있는 .zip 파일인, .odf 파일이다. 이 문서를 보면서, 다음과 같은 사실들을 발견했다. META-INF는 .odf 문서의 콘텐트 리스트인 manifest.xml을 포함하고 있는 폴더이다. Configurations2는 상태 바, 메뉴 같은 UI를 포함하고 있는 폴더이다. 현재까지는 무시해도 좋다. Thumbnails은 작은 .png 이미지를 포함하고 있는 폴더이다. content.xml은 내가 입력했던 실제 데이터 파일이다. meta.xml은 문서에 대한 정보를 포함하고 있는 파일이다. 생성자, 수정일, 기타 상세 정보를 포함하고 있다. mimetype은 "application/vnd.oasis.opendocument.spreadsheet" 스트링을 포함하고 있는 파일이다. settings.xml은 Open Office 설정 내용들을 포함하고 있는 파일이다. styles.xml은 스프레드시트에 대한 포맷팅 정보를 포함하고 있는 파일이다. 따라서, 웹 애플리케이션과 Open Office간 데이터를 교환해야 한다면, 전체 .odf 파일이 아닌 내부 content.xml 파일에 주목해야 한다. 이 파일에는 무엇이 있을까? 17,629개의 문자와, 23개의 XML 네임스페이스, 63 줄의 스타일링 정보가 포함되어 있고, 모든 셀에는 스타일 정보가 들어있다. 이것은 데스크탑 스프레드시트 애플리케이션에는 합리적인 대안이지만, 네트워크를 통해서까지 이렇게 불필요한 정보를 처리하느라 시간을 허비하고 싶지는 않다. Listing 2는 실제 데이터의 한 행(row)이다. Listing 2 <table:table-row table:style-name="ro3"> <table:table-cell office:value-type="string"> <text:p>Room of One's Own</text:p> </table:table-cell> <table:table-cell table:style-name="Default" office:value-type="string"> <text:p>Journal</text:p> </table:table-cell> <table:table-cell table:style-name="ce2" office:value-type="string"> <text:p>Hyacinth Blue; Fabrication; Thanksgiving; Spilling the Peas</text:p> </table:table-cell> <table:table-cell table:style-name="ce5" office:value-type="date" office:date-value="2005-05-10"> <text:p>10 May 2005</text:p> </table:table-cell> <table:table-cell table:style-name="ce5" office:value-type="date" office:date-value="2005-09-01"> <text:p>1 Sep 2005</text:p> </table:table-cell> <table:table-cell table:style-name="ce5" office:value-type="date" office:date-value="2006-10-01"> <text:p>1 Oct 2006</text:p> </table:table-cell> <table:table-cell table:style-name="ce5" office:value-type="date" office:date-value="2006-09-01"> <text:p>1 Sep 2006</text:p> </table:table-cell> <table:table-cell office:value-type="string"> <text:p>Hyacinth Blue</text:p> </table:table-cell> <table:table-cell table:style-name="ce6" office:value-type="currency" office:currency="CAD" office:value="50"> <text:p>50.00 CAD</text:p> </table:table-cell> <table:table-cell office:value-type="string"> <text:p>2 Copies of Publication Issue</text:p> </table:table-cell> <table:table-cell table:style-name="ce7" office:value-type="currency" office:currency="CAD" office:value="1.12"> <text:p>1.12 CAD</text:p> </table:table-cell> <table:table-cell table:style-name="ce7" /> <table:table-cell table:number-columns-repeated="244" /> </table:table-row> 데이터를 XHTML에 삽입하는 것은 어떨까? 이 같은 경우, 파싱이나 포맷팅을 할 필요 없이, Listing 3처럼, 직접 디스플레이 할 수 있다. Listing 3 <html><body><ul> <li><dl> <dt>publisher</dt><dd>Room of One's Own</dd> <dt>type</dt><dd>Journal</dd> <dt>titles</dt><dd><ul> <li>Hyacinth Blue</li> <li>Fabrication</li> <li>Thanksgiving</li> <li>Spilling the Peas</li> </ul></dd> <dt>submitted</dt><dd>2005-05-10</dd> <dt>accepted</dt><dd>2005-09-01</dd> <dt>published</dt><dd>2006-10-01</dd> <dt>payment received</dt><dd>2006-09-01</dd> <dt>titles accepted</dt><dd><ul> <li>Hyacinth Blue</li> </ul></dd> <dt>expenses</dt><dd><dl> <dt>postage</dt><dd>CAD 1.12</dd> </dl></dd> <dt>payment</dt><dd><ul> <li>CAD 50.00</li> <li>2 Copies of Publication Issue</li> </ul></dd> </dl></li> <li><dl> <dt>publisher</dt> <dd>Surrey International Writers' Competition</dd> <dt>type</dt><dd>Contest</dd> <dt>titles</dt><dd><ul> <li>The Thirteenth Child</li> </ul></dd> <dt>submitted</dt><dd>2006-08-31</dd> <dt>accepted</dt><dd>2006-09-26</dd> <dt>published</dt><dd>2006-10-20</dd> <dt>payment received</dt><dd>2006-10-20</dd> <dt>titles accepted</dt><dd><ul> <li>The Thirteenth Child</li> </ul></dd> <dt>expenses</dt><dd><dl> <dt>postage</dt><dd>CAD 1.05</dd> <dt>entry fee</dt><dd>CAD 15.00</dd> </dl></dd> <dt>payment</dt><dd><ul> <li>CAD 150.00</li> <li>Honorable Mention</li> <li>Copy of Anthology</li> </ul></dd> </dl></li> <li><dl> <dt>publisher</dt><dd>Word on the Street</dd> <dt>type</dt><dd>Invited Reader</dd> <dt>event</dt><dd>10 Minutes of readings</dd> <dt>event date</dt><dd>2006-09-24</dd> <dt>payment</dt><dd><ul> <li>T-Shirt</li> <li>Lunch</li> </ul></dd> </dl></li> <li><dl> <dt>publisher</dt><dd>Paideusis: The Journal of the Canadian Philosophy of Education Society</dd> <dt>type</dt><dd>Refereed Journal</dd> <dt>titles</dt><dd><ul> <li>To Carry Over: Metaphor Invents Us (seven poems)</li> </ul></dd> <dt>submitted</dt><dd>2006-10-13</dd> <dt>accepted</dt><dd>2006-10-16</dd> <dt>published</dt><dd>Pending</dd> <dt>titles accepted</dt><dd>All</dd> </dl></li> </ul></body></html> 이것은 데이터를 HTML로 단순히 매핑한 것이다. 기본 스타일링이 충분하지는 않지만, 크로스 플랫폼(cross-platform) 방식으로, CSS를 사용하면 스타일링 하기가 매우 쉽고, DOM을 사용하여 데이터를 쉽게 조작할 수 있다. 추가된 HTML 코드 때문에 약간 부풀려 보이지만, 그렇게 심한 것은 아니다. 이 예제는 XOXO outline Microformat(참고자료)와 매우 비슷하고, class="outline"을 첫 번째 <ul /> 엘리먼트에 붙인다면, XOXO 아웃라인이 될 것이다. 여기에 커스텀 XML을 사용하여 콘텐트를 추가할 수 있고, 디스크립션 리스트를 <submission/> 엘리먼트로 대체했다. 하지만 이 예제의 경우, 간결함이나 가독성 측면에서는 별로 얻은 것이 없다. 간결함을 원한다면, JavaScript Object Notation (JSON)을 고려해 볼 수 있다. Listing 4 { "publisher": "Room of One's Own", "type": "Journal", "titles": ["Hyacinth Blue", "Fabrication", "Thanksgiving", "Spilling the Peas"], "titles accepted": ["Hyacinth Blue"], "submitted": "2005-05-10", "accepted": "2005-09-01", "published": "2006-10-01", "payment received": "2006-09-01", "expenses": [{"postage": "CAD 1.12"}], "payment": ["CAD 50.00", "2 Copies of Publication Issue"]}, { "publisher": "Surrey International Writers' Competition", "type": "Contest", "titles": ["The Thirteenth Child"], "titles accepted": ["The Thirteenth Child"], "submitted": "2006-08-31", "accepted": "2006-09-26", "published": "2006-10-20", "payment received": "2006-10-20", "expenses": [{"postage": "CAD 1.05"}, {"postage": "CAD 15.00"}], "payment": ["CAD 150.00", "Honorable Mention", "Copy of Anthology"]}, { "publisher": "Word on the Street", "type": "Invited Reader", "event": "10 Minutes of readings", "event date": "2006-09-24", "payment": ["T-Shirt", "Lunch"]}, { "publisher": "Paideusis: The Journal of the Canadian\ Philosophy of Education Society", "type": "Refereed Journal", "titles": ["To Carry Over: Metaphor Invents Us \ (seven poems)"], "titles accepted": "All", "submitted": "2006-10-13", "accepted": "2006-10-16", "published": "Pending"} ] Listing 4를 보면, HTML 인코딩과 모두 같은 내용이지만, 이것은 JavaScript의 서브셋(subset)이기 때문에, JavaScript 객체, 리스트(list), 스트링(string)으로서 직접 데이터에 액세스 할 수 있다. 이 포맷은 단순하고 간결하며, 이전 포맷에 있는 모든 정보를 포함하고 있다. 게다가, 구조도 잘 보존하면서 Semi-structured 데이터에도 잘 맞는다. 이것으로 간결성에 대한 해결책은 얻었지만, 이것보다 더 단순해 질 수 있다. 첫 번째 예제로 다시 돌아가서, 스프레드시트에 데이터를 저장해 보자. 한 스프레드시트에서 다른 스프레드시트로 데이터를 옮기는 방식 중에는 Comma-Separated Value (CSV)가 있다. Listing 5를 보자. Listing 5 "Publisher", "Type", "Titles", "Submitted", "Accepted/Rejected", \ "Published", "Payment Received", "Titles Accepted", "Payment", \ "In Kind", "Postage", "Fees" "Room of One's Own", "Journal", "Hyacinth Blue; Fabrication; \ Thanksgiving; Spilling the Peas", 10 May 2005, 1 Sep 2005, \ 1 Oct 2006, 1 Sep 2006, "Hyacinth Blue", 50.00 CAD, \ "2 Copies of Publication Issue", 1.12 CAD, "Surrey International Writer's Competition", "Contest", \ "The Thirteenth Child", 31 Aug 2006, 26 Sep 2006, 20 Oct 2006, \ 20 Oct 2006, "The Thirteenth Child", 150.00 CAD, "Honorable Mention, \ Copy of Anthology", 1.05 CAD, 15.00 CAD "Word on the Street, Vancouver", "Invited Speaker", \ "10 Minutes of Readings", , , 24 Sep 2006, , , , "T-Shirt, Lunch", , "Paideusis: The Journal of the Canadian Philosophy of Education \ Society", "Refereed Journal", "To Carry Over: Metaphor Invents Us \ (seven poems)", 13 Oct 2006, 16 Oct 2006, "(Pending) Nov 2006", , \ "All", , , "Email", Listing 5는 어느 정도까지 간결해 질 수 있는지를 보여주는 것 같다. JSON과 CSV의 중대한 차이도 보인다. CSV는 일반적인 기술이고, 결코 표준화 되어 있지 않으며, 오직 ASCII 텍스트만을 취하는 반면, JSON은 명확하게 표준화 되었으며, Unicode의 UTF-8 인코딩 사용에 대해서도 정의를 내린다. 따라서, CSV 예제의 경우 ASCII 범위 이외의 어떤 텍스트도 사용하지 않지만, JSON(그리고 XML)은 어떤 텍스트와도 잘 작동한다. 위로 Atom 연결 Atom Syndication Format은 필자, 발행일 등, Fame not Fortune의 정보와 몇 가지 중복되는 사항들이 있다. 이 모든 데이터를 하나의 피드(feed)에 놓고, XML로 포맷하고, 이와 동시에 표준 애그리게이터를 사용하여 이 내용들이 검색되도록 할 수 있다. 바로 이것이 나의 애플리케이션과 다른 툴들을 구별하는 요소가 된다. Listing 6은 Atom 피드의 모습이다. (간략하게 도입 부문만 소개하고자 한다.) Listing 6 <?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> <title>Fame not Fortune</title> <subtitle>Recent submissions</subtitle> <link href="http://example.org/famenotfortune"/> <updated>2006-12-03T20:37:16Z</updated> <author> <name>Daniela Elza</name> </author> <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id> <entry> <title>Hyacinth Blue</title> <link href="http://example.org/famenotfortune/hyacinthblue"/> <id>urn:uuid:68C0BAAB-C955-45F9-BDD6-21A22FC809AF</id> <updated>2006-12-01T20:37:16Z</updated> <published>2006-10-01T12:12:12Z</published> <category term="Journal"/> <content type="xhtml"> <div xmlns="http://www.w3.org/1999/xhtml"> <dl> <dt>publisher</dt><dd>Room of One's Own</dd> <dt>titles</dt><dd><ul> <li>Hyacinth Blue</li> <li>Fabrication</li> <li>Thanksgiving</li> <li>Spilling the Peas</li> </ul></dd> <dt>submitted</dt><dd>2005-05-10</dd> <dt>accepted</dt><dd>2005-09-01</dd> <dt>payment received</dt><dd>2006-09-01</dd> <dt>expenses</dt><dd><dl> <dt>postage</dt><dd>CAD 1.12</dd> </dl></dd> <dt>payment</dt><dd><ul> <li>CAD 50.00</li> <li>2 Copies of Publication Issue</li> </ul></dd> </dl> </div> </content> </entry> </feed> Listing 6이 낯설지가 않다면, Atom Entry 엘리먼트에 데이터에 필요한 모든 필드들이 없고, 대부분의 엔트리가 <content/> 태그로 래핑된 XHTML 예제이기 때문일 것이다. published 필드와 author를 약간 변경할 수도 있었지만, published 필드의 남용일 뿐이다. 고유의 네임스페이스를 만들어서, 추가 필드로 Atom Entry를 확장할 수 있지만, 어떤 기존 애그리게이터나 피드 리더기도 그 정보를 사용할 수 없기 때문에 의미가 없다. 단순히 Atom 인벨롭으로 XHTML 예제를 래핑하여 애플리케이션에 동기화 지원을 할 수 있지만, 순수하게 데이터 지향 관점에서 본다면 Atom은 어떤 장점도 없다. 애플리케이션의 데이터를 이동할 때, Atom Entry로 래핑하고, Atom Publishing Protocol (참고자료)을 사용하면 도움이 될 것이다. Atom을 사용하고 싶다면, 데이터 포맷 선택에 제한이 생긴다. Atom <content/> 태그에는 세 가지 데이터 유형, 텍스트(JSON 포맷), HTML, XHTML이 포함된다. Atom을 먼저 확장하지 않고는, Atom에 임의의 XML 콘텐트를 삽입할 수 없다. 따라서, Atom 통합을 할 경우 다른 데이터 포맷 결정에도 영향을 줄 수 있기 때문에, 데이터에 동기화를 지원할 것인지의 여부를 먼저 결정해야 한다. 위로 예제 Ajax 웹 사이트나 웹 애플리케이션을 구현할 때 결정해야 할 것들이 많다. 기본적으로, 어떤 데이터 포맷을 사용할 것인지를 결정해야 한다. 나는 이 글을 통해서, 그러한 결정들을 내리는데 참조할 수 있는 몇 가지 제안을 했었다. 앞서 언급한 내용을 다시 반복하자면, 데이터에는 JSON 문서에는 XML (XHTML) 신디케이션에는 Atom (Atom Publishing Protocol 지원) 공유 사이트... Digg del.icio.us Slashdot 여러 가지 대안들과 선택 원칙들을 설명했다. 물론, 모든 사안들 마다 특성을 갖고 있고, 예외는 어디에나 존재하기 때문에 어떤 것도 단정지을 수는 없다. 이 가이드라인이 나에게는 잘 맞았던 것처럼, 여러분에게도 도움이 되길 바란다. 의견이나 제안 사항이 있는 경우, 언제라도 환영한다. 기사의 원문보기 XML Matters: Ajax tradeoffs: The many flavors of XML 참고자료 교육 XML Alternatives XML Matters: MochiKit (David Mertz, developerWorks, 2006년 11월): Javascript용 고급 라이브러리인 MochiKit에 대해 배워봅시다. Python 프로그래밍 느낌을 가진 Javascript를 만들 수 있습니다. XML Matters: YAML improves on XML (David Mertz, developerWorks, October 2002) Ajax: A New Approach to Web Applications Microformats Introducing JSON Markdown Textile OPML (Outline Processor Markup Language) SVG: Scalable Vector Graphics X3D: 3D for the Web Docbook Introduction to DITA (Don Day, Michael Priestley, David Schell, developerWorks, September 2005) Thinking XML: The open office file format (Uche Ogbuji, developerWorks, January 2003) RDF/XML Syntax Specification (Revised) The Atom Syndication Format IBM XML certification XML technical library developerWorks technical events and webcasts 제품 및 기술 얻기 Simple JSON IBM 시험판 SW 다운로드 토론 XML 존 포럼 developerWorks blogs 필자소개 Dethe Elza는 http://livingcode.org/에서 적극적으로 활동하고 있다. 제안이나 권고 사항은 delza@livingcode.org로 보내기 바란다. http://gnosis.cx/publish/를 방문하면 David Mertz(mertz@gnosis.cx)의 열정의 일면을 볼 수 있다. 어떤 제안이나 권고도 환영한다. http//gnosis.cx/TPiP/에서 그의 저서 "Text Processing in Python"을 만나볼 수 있다.

출처 : IBM developerworks