ajax로 검색한 결과 :: 시소커뮤니티[SSISO Community]
 
SSISO 카페 SSISO Source SSISO 구직 SSISO 쇼핑몰 SSISO 맛집
추천검색어 : JUnit   Log4j   ajax   spring   struts   struts-config.xml   Synchronized   책정보   Ajax 마스터하기   우측부분

회원가입 I 비밀번호 찾기


SSISO Community검색
SSISO Community메뉴
[카페목록보기]
[블로그등록하기]  
[블로그리스트]  
SSISO Community카페
블로그 카테고리
정치 경제
문화 칼럼
비디오게임 스포츠
핫이슈 TV
포토 온라인게임
PC게임 에뮬게임
라이프 사람들
유머 만화애니
방송 1
1 1
1 1
1 1
1 1
1

ajax로 검색한 결과
등록일:2008-04-02 15:01:15
작성자:
제목:XML Matters: Ajax: XML의 다양한 대안들 (한글)


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

developerWorks
문서 옵션

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 Spreadsheet example

벌 써, 몇 가지 문제가 드러나고 있다. 특히, 스프레드시트는 트래킹에 맞는 인터페이스가 아니다. 대상 데이터는 매우 유연하기 때문에, 많은 칼럼들이 채워지지 않았고, 아내도 스프레드시트를 사용하는 것에 익숙하지 않았다. 웹 애플리케이션을 구현해야 한다는 나의 생각이 옳았다. 물론, 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 Digg
del.icio.us del.icio.us
Slashdot Slashdot

여 러 가지 대안들과 선택 원칙들을 설명했다. 물론, 모든 사안들 마다 특성을 갖고 있고, 예외는 어디에나 존재하기 때문에 어떤 것도 단정지을 수는 없다. 이 가이드라인이 나에게는 잘 맞았던 것처럼, 여러분에게도 도움이 되길 바란다. 의견이나 제안 사항이 있는 경우, 언제라도 환영한다.

기사의 원문보기



참고자료

교육

제품 및 기술 얻기

토론


필자소개

Photo of Dethe Elza

Dethe Elza는 http://livingcode.org/에서 적극적으로 활동하고 있다. 제안이나 권고 사항은 delza@livingcode.org로 보내기 바란다.


Photo of David Mertz

http://gnosis.cx/publish/를 방문하면 David Mertz(mertz@gnosis.cx)의 열정의 일면을 볼 수 있다. 어떤 제안이나 권고도 환영한다. http//gnosis.cx/TPiP/