최근 웹표준과 웹 접근성이 화두가 되면서 많은 사람들의 관심을 가지고 있으시다고 생각합니다.
어떤 분들은 단지 웹표준 준수 코딩을 div 코딩이라고 부르기도 합니다. 테이블을 단지 div로 교체 하는 일도 벌어집니다
아마도 div 코딩이라는 말때문에 벌어진 일이 아닌가 하는 생각을 해봅니다.
사실 웹표준이라는건 의미에 맞는 태그들을 사용하자는 것인데 말이죠.. 안타깝습니다.

저도 웹표준 과 웹접근성 그리고 시각장애인들이 사용할 수 있는 사이트를 만들던중 제목과 같이 사실 시각장애인이 우리 보다 더 많은 것을 보고 있다는 생각이 들었습니다.

물론 많은 홈페이지들이 단순히 보여지는 것만을 위해서 코딩하거나 제작 하기 때문에 시각장애인들이 접근하고 사용하기가 매우 어렵지만..
실상 시각장애인들이 사용하시는 스크린 리더기를 사용하는것을 옆에서 지켜본 결과 리더기에서는 css 스타일을 필요로 하지 않기 때문에 파싱된 DOM 만을 읽어 들이기 때문에 DISPLAY:NONE 속성은 읽혀지지 않는다... 이렇게 되면 우리가 보고 있지 않은, 숨겨놓은 것들도 접근이 된다는 것입니다. (이렇게 생각해보면 보는 것만으로 사용하는 사용자들은 오히려 접근이 제한되는 컨텐츠들이나 속성들이 있는 것이 된다. 그러니까 피차 일반인거다.)
그래서 사이트 제작 당시 시각장애인분을 모셔놓고 시연을 부탁 드렸는데 난감한 질문을 하셨다...
"여기있는 체크박스는 어떤 용도지요?" 
아마도 display:none 속성으로 체크박스를 숨겨 놓았을 것이고, 당연히 그에 맞는 label 요소는 없을 것이었다.
결국 그분의 질문에 대답을 할 수 없었고 소스 분석으로 그 체크박스를 찾아 내었다..

시각장애인분께서 시연 하시면서 스크린 리더는 DOM파싱만 되면 바로 내용을 확인 할수 있고, 스크린 리더기에서 자주 사용하는 내용이나 링크를 등록할 수 있기 때문에 훨씬 빠른 접근이 가능하다 하셨다.

그렇다 시각 장애를 가지고 계신 분들이라고 해서 인터넷을 전혀 못사용하거나, 그저 몇몇 사이트만 접근 할 수 있는 상황은 아니다. 그리고 그분들이 사용 가능하게 만드는 것도 크게 어려운 일은 아니다.

시연 도중에 자주 사용하시는 이메일을 보여주셨는데 마침 시연 하는날 리뉴얼이 되있었나보다. 우리는 쉽게 어디다 글을 쓰고 어디다 주소를 적어야 할지 알 수 있었지만, 그분은 자주 가는 메뉴로 넘어갔을때 그 위치가 나오지 않았다. 우리는 전혀 몰랐던 사실이었다.모양은 바뀌지 않았지만 DOM 구조가 바뀐 모양이다. 워낙 능숙 하신 분이어서 이내 원하시는 곳을 찾으 실수 있었다.

이날의 경험은 값진 것이었고 .. 조금은 충격적인 것이었다.

그렇다 시각장애인은 우리보다 더 많은 것을 보고 있다.
그렇다보니 불편을 느끼는 것이다. 상위 호환이 안되는 것이다.

우리는 아직 하위 버전인것이다. 지금 하고 있는 것처럼 더 활발한 연구와, 기술 보급을 통해서 상위버전으로 업데이트해야 할 것이다. 


ps. 처음으로 글다운 글을 써보는 것 같다... 머 원래 논리적이지 못하고, 말주변이 없어서 간간히 뭔소린가... 아니면 당연한거잖아 하겠지만... 그리고 존대말에서 갑자기 반말로 바뀌는 등... (귀찮아서 수정을 안했습니다.) 
이런 모든 장애 사항에도 불구 하고 읽어주셔서 감사합니다.~

메타(META)태그란


메타태그는 html문서의 <head>와</head>사이에 입력하는 특수태그로서 문서의 설정요소 들을 http서버에서 만들어진 특정 프로토콜 (컴퓨터간의 정보 교환을 위한 규칙을 말함) 에 연결합니다. 검색 사이트는 디렉토리 서비스라는 형식이 있고 검색 로봇이라는 것이 있는데 디렉토리 서비스라는 것은 사용자가 사이트에 관한 정보를 일일이 입력해서 검색을 하면 검색엔진에 등록된 사이트 중에서 입력된 정보와 적합한 사이트를 연결시켜 주는 방식이고 검 색로봇이라는 것은 대부분 메타태그를 이용하여 정보를 찿습니다. html문서의 <head> 부분 에삽입이 되면이 검색로봇이 검색엔진에 등록된 사이트를 주기적으로 돌아다니며 메타태그 를 색인해서 데이타를 갱신하게 됩니다. 따라서 자신의 홈페이지를 작성할때 메타태그를 적 절히 삽입해서 검색사이트 에 등록을 하는것이 바람직 하다고 봅니다.마감태그는 없습니다.


홈페이지를 작성한 도구를 알려주는 메타태그 소스
<meta name="generator" content="메모장">


메타의 한글지원 태그

인터넷 익스플로러5.0이나 넷스케이프 커뮤니페이터4.5에서는 언어를 자동으로 지원하므로 문서에 charset 을 설정하지 않아도 한글이 깨지지는 않습니다.그러나 웹  버전이 다른 경우한글이 깨져 나오는 경우가 있으므로 한글이 있는 html문서를 작성한다면 항상 다음과 같은 태그를 사용하는 것이 좋습니다.그러나 주의할 점은 다음과 같이 한글폰트charset=euc-kr로 설정을 해 주면 인터넷 익스플로러 에서는 아무 문제가 없지만 넷스케이프의 경우는 기본적으로 영문폰트(Western(ISO-8859-1))로 인코딩하여 문서를 보여 줍니다. 따라서 <meta charset=euc-kr>을 설정 하면 넷스케이프에서는 한글이 깨져 나오기도 합니다.그런데 반대로<meta charset=iso-8859-1>사용하면 넷스케이프에서는 한글이 깨지지 않는데 익스플로러에서 문서를 보게되면 최신 버전임에도 한글이 거의 다 깨져 나옵니다.이때는 메타 소스를 수정 하는 수 밖에 없습니다 익스플로러 에서는 <meta charset=euc-kr>을 설정해 주고 넷스케이프에서는 <meta charset=iso-8859-1> 을 설정해서 삽입해 주면 한글이 깨지지 않는답니다.다음과 같이 각각 다르게 메타태그를 삽입해 주면 됩니다
익스플로러 <meta http-equiv="Content-Type" content="text/html;charset=euc-kr">넷스케이프 <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">


주제어 설정 메타태그

주제어 메타태그를 삽입하면 검색엔진에서 키워드로 검색을 했을때 수없이 많은 사이트중에우선순위로 상위리스트 그룹에출력이 됩니다.자신이 만든 홈페이지가 키워드 검색시에 상위리스트에 입력이 되게 하려면 다음과 같은 메타태그 를 쓰면됩니다.단어는 콤마로 구분하죠 <meta name="keywords" content="태그,tag, html,태그연습,태그연습장, 태그기초,태그공부,태그의모든 것,태그란?,자바스크립트,자바에플릿"> 검색엔진에서 위에 나열된 단어중 태그 혹은 태그연습 이라고 검색어를 입력하고 검색키 를누르면 검색 사이트에 출력이 됩니다.물론 자신의 사이트가 검색엔진에 등록이 되어 있어야 겠죠


홈페이지에 대한 소개를 나타내는 메타태그

검색엔진 에 출력된 사이트 들을 보면 홈페이지 이름과 함께 홈페이지에 대한 설명이 입력되어 있습니다.키워드와 함께 검색엔진으로 검색 하였을때 홈페이지 에 대한 설명 부분은 여기에 설정된 글들이 나타나는 것입니다 메타태그가 지정되어 있지 않은 경우 검색로봇은 페이지상 단으로 부터 몇줄만 설명으로 가져가기 때문에 검색자에게 정확한 결과를 보여줄 수가없겠죠 아래소스 content 부분만 자신의홈에 맞게 수정하면됩니다 <meta name="description" content="홈페이지를 꾸밀수 있는 자바에플릿 자바스크립트소스모음과스타일시트 각종 태그소스 자료 제공">


몇초후 다음 페이지로 자동 로딩하기

자신의 홈페이지 주소가 바뀌었거나 첫화면에 몇초동안 의 로고나 이미지를 보여준 후 메인페이지로 갈때나 슬라이드 효과를 낼때 사용합니다. CONTENT=5는 5초후 를 의미 합니다
<meta http-equiv="refresh" content="5;URL=http://www.netian.com">


  트레지션 효과 메타태그
  페이지를 이동할때 화면을 여러가지 모양으로 바꿔주는 태그입니다.
<meta http-equiv="Page-Exit" content="revealtrans(duration=2.0,transition=23)">
<meta http-equiv="Page-Enter" content="revealtrans(duration=2.0,transition=23)">

Java 의 Vector 클래스는 내부적으로 배열을 사용하고 있다. 따라서 Vector 의 자바스크립트 버전을 만들기 위해서는 Array 객체에 대한 빵빵한 지식이 필요하다 (없어도 된다. 그러나 있으면 매우 좋다). 자! 배열의 기초와 유용한 메쏘드들을 살펴보자.


배열의 생성

1. 생성자를 이용한 생성

  - new Array(arrayLength)

    ex) friends = new Array(3); // 크기가 3 인 배열 생성

  - new Array(element0, element1, ... , elementN)

    ex) friends = new Array("개똥이", "소똥이", "말똥이"); // 크기 3인 배열 생성(값이 채워짐)

2. 직접 생성

  friends = ["개똥이", "소똥이", "말똥이"];


간접적인 배열 길이의 증가

배열의 길이는 현재 배열의 길이보다 큰 인덱스를 사용하면 자동으로 증가한다. 아래는 배열의 길이가 0 인 객체 생성 후 99번째 요소에 값을 할당하여 배열의 길이가 100 으로 증가한 예이다.

friends = new Array();

friends[99] = "새똥이";


메쏘드 종류

concat : 두개의 배열을 합쳐 새로운 배열을 리턴한다. 원본 배열은 변하지 않는다.

문법

  arrayName.concat(arrayName2, arrayName3, ... , arrayNameN)

인자

  arrayName2, ... , arrayNameN - 합쳐질 인자들

예제

  두 배열을 합치는 예

  alpha = new Array("a", "b", "c");

  numeric = new Array(1, 2, 3);

  alphaNumeric = alpha.concat(numeric); // ["a", "b", "c", 1, 2, 3] 배열 생성


join : 모든 요소가 구분자로 이어진 문자열을 리턴한다. 디폴트 구분자는 comma(,) 이다.

문법

  arrayName.join(separator)

인자

  separator 요소와 요소 사이에 사용될 구분자 문자열

예제

  friends = new Array("소똥이", "개똥이", "말똥이");

  strFriends1 = friends.join(); // 소똥이,개똥이,말똥이

  strFriends2 = friends.join(", "); // 소똥이, 개똥이, 말똥이

  strFriends3 = friends.join(" + "); // 소똥이 + 개똥이 + 말똥이


pop : 배열의 마지막 요소를 삭제한 후 그 값을 리턴하고 배열의 크기를 줄인다.

문법

  arrayName.pop()

인자

  없음

예제

  // 말똥이가 pop 되고 배열에는 "개똥이", "소똥이"만 남는다.

  // 배열크기도 2로 줄어든다.

  friends = ["개똥이", "소똥이", "말똥이"];

  popped = friends.pop(); // popped 에 말똥이가 할당된다.


push : 배열에 하나 또는 여러개의 값을 넣고 새로운 배열의 길이를 리턴한다.(배열길이 증가)

문법

  arrayName.push(element1, element2, ... , elementN)

인자

  element1, element2, ... , elementN - 추가될 요소들

예제

  friends = ["개똥이", "소똥이"];
  pushed = friends.push("말똥이", "새똥이"); // ["개똥이", "소똥이", "말똥이", "새똥이"]

  alert(pushed); // 4


reverse : 배열 요소를 역순으로 재배치한다(첫번째 요소는 마지막으로, 마지막 요소는 처음으로).

문법

  arrayName.reverse()

인자

  없음

예제

  myArray = new Array("1", "2", "3");

  myArray.reverse(); // ["3", "2", "1"]


shift : 첫번째 요소를 삭제하고 배열의 길이를 하나 줄인 후, 삭제된 요소를 리턴한다.

문법

  arrayName.shift()

인자

  없음

예제

  friends = ["개똥이", "소똥이", "말똥이"];

  shifted = friends.shift(); // ["소똥이", "말똥이"]

  alert("삭제된 요소는 " + shifted + " 입니다."); // 개똥이


slice : 얇게 썬 슬라이스 치즈가 생각난다(^^). 배열의 일부를 잘라내어 새로운 배열을 리턴한다.

문법

  arrayName.slice(begin[,end]) : [] 은 선택사항임

인자

  begin - 0보다 큰 시작 인덱스 (필수)

  end - 0보다 큰 끝 인덱스 (선택). 지정되지 않으면 배열의 끝까지 복사된다.

예제

  numbers = ["0", "1", "2", "3", "4"];

  sliced1 = numbers.slice(2, 3); // ["2"]

  sliced2 = numbers.slice(2); // ["2", "3", "4"]


sort : 배열의 요소를 정렬한다.

문법

  arrayName.sort([compareFunction])

인자

  compareFunction - 정렬방법을 지정한 함수.

     생략시에는 요소들의 toString() 값을 사전순서(Dictionary order) 대로 정렬한다.

     compareFunction(a, b) 에서

        1) a > b : 0 보다 큰 값 리턴

        2) a = b : 0 리턴

        3) a < b : 0 보다 작은 값 리턴

예제

  // 역행 정렬

  function descComparator(a, b) {

      return b - a;

  }


  // 순행 정렬

  function ascComparator(a, b) {

      return a - b;

  }


  numbers = ["0", "1", "2", "3", "4"];

  numbers.sort(); // ["1", "2", "3", "4", "5"]

  numbers.sort(ascComparator); // ["1", "2", "3", "4", "5"]

  numbers.sort(descComparator); // ["4", "3", "2", "1", "0"]


splice : 이전 배열요소를 삭제하고 새로운 내용물을 추가하는 형태로 배열 내용을 변경한다. 삭제된 요소들은 리턴된다. Vector 와 유사한 기능을 하므로 숙지하자.

문법

  arrayName.splice(index, howMany, [element1][, ..., elementN])

인자

  index - 변경하고자 하는 요소의 시작 인덱스

  howMany - 삭제하고자 하는 이전 배열요소 갯수.

  element,...,elementN - 추가하고자 하는 배열 요소들

예제

  // numbers[2]부터 2개("2", "3")를 삭제하고 그 자리에 "5"와 "6" 을 삽입한다.

  numbers = ["0", "1", "2", "3", "4"];

  spliced = numbers.splice(2, 2, "5", "6"); // ["0", "1", "5", "6", "4"]

  alert(spliced); // "2", "3"


unshift : 하나 또는 여러개의 요소를 배열의 왼쪽에 추가한다. 배열길이는 증가한다.

문법

  arrayName.unshift(element1,..., elementN)

인자

  element1,...,elementN - 배열의 앞쪽에 들어갈 요소들

예제

  numbers = ["0", "1", "2"];

  numbers.unshift("-2", "-1"); // ["-2", "-1", "0", "1", "2"]


아거거.. 기양 써내려가는 글이 아닌 레퍼런스 문서를 만드는 것은 역시 힘들고 지루하다..

아는것이 힘이다. 많이 참고하시길..

CSS를 짜다보면 어쩔수 없이 핵과 마주해야합니다. 그나마 있어줘서 고마운 핵... 하지만 우리는 그 이름조차 모르고 있지는 않나요? ( --; 무슨 공익광고인가...)

그래서 이름과 용법 등을 정리해 보았습니다.

박스모델 핵 (Box Model Hack)
<적용브라우저 : IE4, IE5, IE5.5, NS4>

voice-family:"\"}\"";
voice-family:inherit;
property:<value>;

"웹2.0을 이끄는 방탄웹(왜 웹2.0을 방탄웹이 이끄는지는 미스테리)"에 보면 처음 나오는 핵입니다.

IE5.x (IE5, IE5.5 등)에서 div로 지정된 박스의 넓이가 padding과 margin을 적용하면 해석하는 과정에서 큰 오차가 발생하는 관계로 이 부분의 오차를 미연에 방지하고자 적용하는 핵입니다. 하지만, 다른 IE5.x관련 값에도 적용되는 유용한 핵입니다.

(제 경험으로는, DTD를 Strict로 맞춰주면 이 핵을 적용하지 않고도 별 이상없이 구현되었습니다.)

간략화된 박스모델 핵(SMBH, Simplified Box Model Hack)
<적용브라우저 : IE4, IE5 ,IE5.5, NS4, OP5>
말뜻 그대로, 길어서 줄인 것입니다.

* html <selector> {
property:<value>;     <- IE5.x의 값
p\roperty:<value>;  <- 그 외 브라우저의 값
}

카이오 핵(Caio's Hack)
<적용브라우저 : NS4>

/*/*/property:value;/* */
패브라이스 도치법(Fabrice's Inversion)
<적용 브라우저 : IE4, IE5, IE5.5, IE6, IE7, NS6, NS7, OP6, OP7, OP8, SF2>

/*/*//*/property:value;/* */

오웬 핵(Owen's Hack)
<IE4, IE5, IE5.5, IE6, NS4, OP5, OP6>

head:first-child+body div

자식 셀렉터(Child Selector)
<적용 브라우저 : IE4, IE5, IE6, NS4>
원래는 핵이 아닌데, IE 구버전에서 처리할 수 없는 셀렉터를 이용해 핵처럼 이용하는 방법입니다. 이런 핵이 몇개 있는데, 대부분 IE 구버전과 관련있습니다.

body>div

속성 셀렉터(Attribute Selector)
<적용 브라우저 : IE4, IE5, IE6, NS4>
이것 또한 속성셀렉터를 구버전 IE에서 인식하지 못하는 점을 이용한 핵입니다.

html[xmlns] div

스타 HTML 버그(Star HTML Bug)
<적용 브라우저 : IE7, MO1, NS4, NS6, NS7, OP5, OP6, OP7, OP8, SF>
오페라 전용 핵처럼 생각되어질 정도군요.

* html div

넥스트 낫씽 핵(Next to Nothing Hack)
<적용 브라우저 : IE5.5, IE6, MO1, NS4>

*+html div

인라인 하이패스 필터(Inline High Pass Filter)
<적용 브라우저 : IE4, IE5, IE5.5, NS4>

i{content:"\"/*"}
div{property:value}

스타7 핵(Star 7 Hack)
<적용 브라우저 : IE4, IE5, NS4, OP5, OP6, OP7, OP8, SF>

html*#test


언더스코어 핵(Under Score Hack)
<적용 브라우저 : IE7, MO1, NS4, NS6, NS7, OP5, OP6, OP7, OP8, SF>

_property:value

http://centricle.com/ref/css/filters/의 내용을 참고하여, 윈도우용만 적용해 보았습니다.

기타 잘 정리해 둔 내용...


Netscape 4 배제하기
<link rel="stylesheet" type="text/css" href="http://wis1674.tistory.com/css/style.css" media="all" />
Netscape 는 media 속성이 screen 이 아닌 경우 외부 스타일시트를 읽지 못하는 버그가 존재함.

Win IE 3~4, Mac IE 4~4.5, Netscape 4 배제하기
@import url("/css/style.css")
Win IE 4, Mac IE 4 는 인용부호가 "가 아니면 읽지 못하는 버그 존재. IE 3과 Netscape 4는 @import 지원하지 않음.

Mac IE 5 배제하기
H1 { /* \*/ color:red; /* */ }
Holly 핵이라 하며, 주석 안의 내용이 적용되지 않음.

Win IE 4~5 배제하기
H1/**/ { color:red; }
셀렉터 뒤에 /**/ 삽입.

Win IE 4~5, Mac IE 4.5~5 배제하기
H1 { color/* */:red; }
속성과 속성값을 구분하는 콜론(:) 앞에 /* */ 삽입.

Win IE 4~6, Mac IE 4, Netscape 4 배제하기
html>body H1 { color:red; }
셀렉터 앞에 html>body 삽입.

Win IE 6 제외시키기
H1 { color /**/:red; }
속성과 속성값을 구분하는 콜론(:) 앞에 스페이스와 /**/ 삽입.

언더스코어 핵 (_)
H1 { _color:red; }
Win IE 4~6 에 적용.

닷핵 (.)
H1 { .color:red; }
속성 앞에 . 삽입. Win IE 6~7 에만 적용. 타 브라우저는 정확히 확인하지 못했습니다.
이 핵에 대해선 계속 확인중인데 블로그스피어나 여타 서적에는 전혀 언급이 없는 이상한 핵(?)입니다.

해시 핵(#)
H1 { #color:red; }
속성 앞에 # 삽입. Win IE 4~6, Mac IE 5, Opera 7, Mozilla계열, Firefox 에 적용.

스타 핵
*HTML H1 { color:red; }
셀렉터 앞에 *html 삽입. Win IE 4~6, Mac IE 4~5 에 적용.

스타7 핵
HTML*H1 { color:red; }
셀렉터 앞에 html* 삽입(공백없이). Win IE 5.5~6, Mac IE 5, Safari 에 적용.

xmlns 속성 핵
HTML[xmlns] H1 { color:red; }
셀렉터 앞에 속성 선택자를 삽입. Mozilla, Firefox, Opera, Safari 등 속성 선택자를 지원하는 브라우저에 적용.

:root 가상클래스 핵
:root H1 { color:red; }
셀렉터 앞에 :root 가상클래스 삽입. Mozilla, Firefox, Mac IE 5, Safari 등 가상클래스를 지원하는 브라우저에 적용.

Tantek 박스모델 핵
H1 {
    width:500px;
    voice-family: ""}"";
    voice-family:inherit;
    width:400px;
}
Tantek Celik 이 고안한 유명한 박스모델 핵. Win IE 4~5, Mac IE 4, Netscape 4 에서는 voice-family 속성 이전의 스타일 적용. 그외의 브라우저는 뒤의 속성 적용.

단순 박스모델 핵
H1 {
    width:500px;
    w\idth:400px; //Win IE 6, Mac IE 5, Mozilla, Opera, Safari
    \width:450px; // only Win IE 5
}

속성의 첫번째, 두번째 글자 사이에 \를 삽입하면 Win IE 6, Mac IE 5, Mozilla, Opera, Safari 에 적용.
추가로 속성의 앞에 \를 삽입하면 Win IE 5 에만 적용.

IE 7, Opera 적용하기
*+html body H1 { color:red; }
셀렉터 앞에 *+html body 삽입. IE 7, Opera 8 이후 버전 적용. Opera를 배제한 IE7 전용으로 하고 싶을 때는 *+html>/**/body 로 Opera 전용 속성 기술.

IE 7 적용하기
*:first-child+html H1 { color:red; }
셀렉터 앞에 *:first-child+html 삽입. IE 7에만 적용되고, 이외의 브라우저는 앞에서 기술한 셀렉터의 속성 적용.

Win IE 5 패스필터
@media tty {
i{content:"";/*" "*/}}; @import '/css/style.css'; {;}/*";}
}/* */


Win IE 5.5 패스필터
@media tty {
i{content:"";/*" "*/}}@m; @import '/css/style.css';/*";}
}/* */


Win IE 6 패스필터(?)
<!--[if IE 6]><link rel="stylesheet" type="text/css" href="http://wis1674.tistory.com/css/style.css" media="all" /><![endif]-->

Win IE 7 패스필터(?)
<!--[if gte IE 7]><link rel="stylesheet" type="text/css" href="/css/style.css" media="all" /><![endif]-->

모던브라우저 패스필터 (Win IE 5.5 이하, Mac IE 5, Opera 8 이하, Netscape 4 이하 제외)
@import "null?"{";
@import "/css/style.css";
@import "null?"}";

XML의 미래

미래의 XML은 어떤 모습일까?


Elliotte Harold, 교수, Polytechnic University

2008 년 3 월 04 일

Elliotte Rusty Harold가 XML 저장과 관련하여 자신이 생각하는 바를 예상합니다.

비록 느리지만 진보의 수레바퀴는 돌아간다. 마법의 수정구는 흐릿할지 몰라도 XML의 미래는 점차 윤곽이 드러나고 있다. 정확한 시기를 예측하기는 어려우나 적어도 목적지는 분명하다. XML의 미래는 웹, 구체적으로 웹 출판에 있다.

막 상 말하고 보니 웃기다. 웹과 출판은 동음이의(同音異意)가 아니던가? 애초에 웹 자체가 정보를 게시할 목적으로 생겨나지 않았던가? 출판 외에 웹으로 무엇을 할 수 있단 말인가? 아주 많은 일을 할 수 있다. 최근 3년 동안 기존 웹 사이트의 한계를 극복하는 웹 응용 프로그램에 대한 관심이 가히 폭발적으로 증가했다. 문서편집기, 스프레드시트, 게임, 다이어그램 그리기 도구 등 점차 많은 도구가 브라우저로 통합되고 있으며 이러한 추세는 웹 브라우저의 지역 저장소 기능으로 오프라인 작업이 가능해짐에 따라 앞으로 더욱 확산될 전망이다. 그러나 XML은 여전히 웹 1.0 출판에 뿌리를 두고 있으며 우리는 이 사실을 주목해야 한다.

해몽

올 해는 몇 가지 꿈이 이뤄질 전망이다. 네트워크 상에서 응용 프로그램을 배포하고 사용한다는 썬 사의 꿈이 한 걸음 현실로 다가왔다. 충격적이게도 현실에서는 응용 프로그램 언어로 자바(Java™)가 아니라 자바스크립트(JavaScript™)를 선택했지만 말이다. 10여전 전에도 충분히 실현이 가능했지만 경험과 비전과 클라이언트의 관심 부재로 썬 사는 진짜로 멋진 기회를 놓치고 말았다. 이제 회사는 '따라잡기'라는 필사적인 (그리고 실패할) 게임에 뛰어들어 고전 중이다.

브라우저로 운영체제를 대체하겠다는 넷스케이프 사의 꿈도 한 걸음 현실로 다가왔다. 넷스케이프 사는 미래를 내다보는 비전이 있었다. 하지만 불행하게도 원대한 비전을 실현할 비즈니스 능력과 예술적인 감각이 없었다. 그럼에도 불구하고 넷스케이프 브라우저의 직계 후손인 파이어폭스(Firefox)와 모질라 재단(Mozilla Foundation)은 이 용감무상한 신세계를 현실로 만들어 줄 핵심 주자로 활약 중이다.

젊고 민첩한 경쟁사가 자신을 집어 삼킬지도 모른다는 마이크로소프트(Microsoft®) 사의 악몽도 현실로 다가왔다. 회사는 썬 사와 넷스케이프 사에 정신을 파느라 구글이 오피스와 윈도우 시장을 넘본다는 사실을 알아채지 못했다. 지메일(GMail), 구글 독스(Google Docs) 등과 같은 응용 프로그램은 급속하게 기반 운영체제로부터 독립을 선언하고 있다.

물론 브라우저를 돌리려면 아직도 운영체제가 필요하다. 하지만 점차 운영체제 이름 자체는 무의미해지리라. 마이크로소프트 윈도우(Windows®) 운영체제가 돌아가는 한 아무도 PC 제조업체 이름을 신경쓰지 않았던 지난 10여년처럼 말이다. 이제는 구글이 돌아가는 한 아무도 운영체제 개발업체 이름을 신경쓰지 않는 시기가 다가왔다. PC가 그랬듯이 운영체제도 점차 일반재화가 되어가고 있다. 마이크로소프트 윈도우 왕국은 패배했다기보다 버려졌으며, 마이크로소프트 사는 빈 성문을 지키고 있을 따름이다.




위로


이게 대체 XML과 무슨 상관인가?

evalJSon() 옵션

evalJSon() 함수는 나도 안다. 이제껏 살펴 본 일부 Ajax 응용 프로그램으로 판단하건데, 상당수 Ajax 응용 프로그래머보다 내가 evalJson() 함수를 더 잘 안다. 더 나은 방법이 있음에도 많은 Ajax 프로그래머가 eval()을 고집하고 있다.

관 심과 이목을 한 몸에 받아온 기술치고 XML은 이 상황과 거의 무관하다. 혹자는 비동기 자바스크립트(Asynchronous JavaScript) + XML (Ajax)을 들먹이며 Ajax에서 x는 XML을 뜻한다고 주장할지도 모르지만, 실제 이 목적으로 XML을 사용하는 사람은 거의 없다. Ajax라는 약어가 출현함과 거의 동시에 웹 개발자들은 XML을 원시 자바스크립트 코드로 교체하여 데이터로 넘긴 후 eval()로 계산하기 시작했다. 보안 구멍이 훤히 뚫힌 셈이다.

문 제는 자료 형식이 아니라 API에 있다. 구체적으로 DOM(Document Object Model)이라는 API가 문제다. 대다수 개발자들은 DOM부터 배운 후 다른 대안을 배우지 못했다. DOM과 XML을 구분하지 않는 탓에 DOM에 대한 근거 있는 혐오와 XML에 대한 근거 없는 혐오를 혼돈한다. DOM은 최소의 공분모 API가 아니라 최악의 공분모 API다. 일부러 노력해도 DOM보다 못한 XML API를 설계하기 어려울 정도다. 그러나 개발자들은 새로운 기술을 배우기를 극도로 꺼린다. 자바 공동체 내에서는 JDOM과 dom4j가 다소 진전을 보였을 뿐이지만, 자바 공동체를 벗어나면 E4X와 아마라 XML 툴킷(Amara XML Toolkit)처럼 더 나은 대안이 존재한다. 그러나 이 대안들은 거의 알려지지 않았으며 대놓고 거부 당하고 있다. JSON(JavaScript Serialized Object Notation)이라는 천재적인 개념 역시 커다란 취약점이다. JSON은 실행 가능한 자바스크립크 코드이므로 자바스크립트 프로그래머 입장에서는 새로운 내용을 익힐 필요가 없다. 더욱 안전한 데이터 전송 방법이 있더라도 받아들이지 않는다.

널리 사용하는 약어
  • API: application programming interface
  • HTML: Hypertext Markup Language
  • SGML: Standard Generalized Markup Language
  • W3C: World Wide Web Consortium
  • XML: Extensible Markup Language

DOM 은 XML 목에 걸린 맷돌이다. 소프트웨어 개발 분야가 XML을 폭넓게 활용하지 못하는 가장 큰 걸림돌이 DOM이다. 프로그래밍 측면에서 XML은 이 2000파운드짜리 닻을 질질 끌면서 나갈 만큼 나갔다. W3C(World Wide Web Consortium)와 브라우저 제조업체가 DOM을 이성적인 대안으로 교체하지 않는 한(되도록이면 이성적인 대안 여러 가지로 교체하면 좋겠다. 한 API로 모든 문제를 처리하려다가는 DOM짝이 나기 십상이다) XML은 소프트웨어 개발, 특히 (앞으로 점차 중요해지는) 웹 소프트웨어 개발에서 더 이상 앞으로 나가기 어렵다. W3C는 현장 개발자들의 필요를 인식하되 나쁜 명세는 반대해야 한다.

그래서 XML이 죽었느냐고? 천만의 말씀이다. 나는 XML의 미래가 밝고 중요하다고 믿는다. 단지 기존 소프트웨어 개발이나 웹 소프트웨어 개발과는 별다른 관련이 없다고 믿는다. 2008년도 이후에 XML이 움직일 방향을 이해하려면 먼저 1997년 이전으로 돌아가 XML의 기원을 살펴보자.




위로


XML의 기원

XML 은 결코 소프트웨어 개발에 사용하려던 언어가 아니었다. 적어도 초창기에는 그랬다. XML 1.0, XPath, XSLT(Extensible Stylesheet Language Transformation), XML 네임스페이스(XML Namespace), XHTML(Extensible Hypertext Markup Language), DOM 등 초기 명세를 살펴보면 어느 것도 소프트웨어 개발자를 염두에 두지 않았다. XML을 소프트웨어 개발용으로 만들었다면 JSON처럼 리스트와 맵과 다양한 자료 유형을 지원했으리라. XML은 출판, 좀더 구체적으로 웹 출판에 사용하려고 설계한 언어였다.

XML은 전자문서 출판을 목적으로 20여년 동안 사용해 온 기술인 SGML에서 나왔다. IBM®의 코드(Codd) 박사가 데이터를 순서 없는 작은 조각으로 나누어 구조화하는 방법을 깨달았던 바로 그 시기에 같은 IBM의 찰스 F. 골드파브(Charles F. Goldfarb), 에드워드 모셔(Edward Mosher), 레이몬드 로리(Raymond Lorie)는 표 형식으로 정리하기 불가능한 대규모의 정렬된 문서를 구조화하는 방법을 알아냈다. 코드 박사가 재고와 재정 기록같은 비즈니스 데이터를 고려한 반면, 골드파브와 모셔와 로리는 연간 보고서와 항공기 기술 매뉴얼같은 비즈니스 문서를 고려했다.

SGML은 출판 문제를 해결하려는 언어였다. 즉, 프로세서와 문자 집합과 자연 언어와 운영체제와 제조업체가 다른 여러 가지 플랫폼에 흩어진 수십만 장의 문서를 읽고, 쓰고, 보수하고, 고치고, 인쇄하고, 검색하는 방법을 제시하는 언어였다. SGML은 정부 기관과 군대에서 다소 성공을 거두었으며, 오라일리(O’Reilly)와 같은 일부 기술서 출판사가 때때로 사용했을 뿐 일반인들이 사용하기에는 너무 무겁고 복잡했다. 심지어 출판 업계 사람들조차도 꺼릴 정도였다.

SGML의 가장 큰 성공이자 가장 큰 실패는 HTML이었다. 애초에 HTML은 SGML 응용 프로그램으로 출발했으나 브라우저나 편집기나 웹 페이지를 개발하는 사람들 누구도 SGML이 Standard Generalized Markup Language를 줄인 말이라는 사실 외에 SGML에 관해 아는 바가 없었다(이 사실조차 모르는 사람도 많았다). 결국 무질서한 확장으로 말미암아 HTML이 SGML 구조를 따라야 한다는 주장은 급속히 힘을 잃어갔다. 심지어 1996년 당시 존재했던 몇 안 되는 고가 SGML 도구도 실제 사용 중인 HTML의 난잡한 내용을 인식하지 못할 정도였다.

바로 이런 난국을 타계하고자 XML이 나왔다. 다른 한 편으로 SGML을 합리적으로 단순화하여 모두가 충실하게 지킬 표준 부분집합을 만들려는 목적이 있었다. SGML보다 단순한 명세로 SGML보다 널리 받아들여지리라 여겨졌고, 이 점에서 XML은 대체로 성공을 거두었다.

다른 한 편으로 XML은 브라우저 간 호환성 문제와 특이성을 줄이고 형식이 갖춰진(well-formed) 웹을 유도하려는 의도였는데 이 점에서 XML은 대체로 실패를 맛보았다. 엉망진창인 태그 짬뽕을 교체하기는 커녕 XML과 XHTML은 브라우저가 처리해야 할 또 다른 HTML 사투리가 되고 말았다.

성공이든 실패든 XML은 책, 매뉴얼, (가장 중요하게) 웹 페이지를 출판할 목적으로 만들어진 언어다. 소프트웨어 개발에 사용할 의도도 아니었고 소프트웨어 개발에 맞게 최적화되지도 않았다. 환경 설정 파일, 원격 프로시저 호출, 개체 직렬화, 데이터베이스 덤프, 기타 객체 지향 작업을 수행하리라 예측하지도 계획하지도 않았다. 그러니 XML이 이런 잡무에 100% 적합하지 못하더라도 놀랄 일이 아니다. 그럼에도 불구하고 XML은 개발자들에게 이제껏 없었던 가능성을 보여주었다. 플랫폼 독립적이고, 언어 중립적이고, 국제화가 쉬운 자료 형식에다 우수한 공짜 구문 분석기를 구하기도 수월했다. 정수나 부동소수와 같은 자료 유형과 리스트나 맵과 같은 기본 자료 구조가 없다는 단점에도 불구하고 프로그래머들은 이러한 장점을 거부하기 어려웠다.

그러나 프로그래밍은 XML이 원래 의도했던 목적이 아니므로 프로그래밍 언어로서 XML을 판단해서는 안 된다. 프로그래밍 언어로서 강점을 찾거나 가능성을 점쳐서도 안 된다. XML의 강점과 가능성을 찾으려면 원래 XML이 목적한 용도인 출판, 특히 웹 출판으로 돌아가야 한다. 웹에서 출판은 다음과 같은 세 가지 구성요소로 나눠진다.

  • 저작자
  • 출판사
  • 독자

독자쪽은 문제가 없다. 브라우저가 있으니까. 현재 주요 브라우저는 모두 XML을 지원한다. 그러나 저작과 출판과 둘 사이 연결은 이제 막 시작 단계다.




위로


저작

문 서를 출판하려면 작성부터 해야 한다. 이 부분에서 승패는 이미 판가름 났다. XML이 승자다. 이제 주요 오피스 프로그램은 기본적으로 문서를 XML 압축 파일로 저장한다. 여기에는 마이크로소프트 오피스, 오픈오피스, 스타오피스, 워드퍼펙트 오피스, 로터스 노츠(Lotus® Notes®)가 포함된다. 심지어 어도비 일러스트레이터(Adobe® Illustrator®)와 같은 그래픽 응용 프로그램도 이제는 문서를 XML로 저장한다. 아직 이 진영에 속하지 않은 주요 소프트웨어로는 iWorks가 있지만 내년 즈음에는 가담하리라 예상한다.

마크업-중심 편집기의 종말

초창기에는 많은 개발업체가 내장 문서를 트리 형식으로 제어하는 마크업-중심 편집기를 내놓았다. 스윙의 JTree처럼 다양한 트리 컴포넌트를 이용하여 문서를 구현하기는 매우 쉬웠지만 XML 문서를 트리 형식으로 읽고, 쓰고, 편집하려는 사람은 아무도 없었다. 결국 시장에서 사라졌지만 아쉬워하는 사람은 아무도 없었다.

이 러한 변화는 중요한 발전임에도 불구하고 별다른 주목을 끌지 못했다. XML은 (당연히 그래야 하듯이) 사용자에게 보이지 않기 때문이다. 일반 스프레드시트 사용자 입장에서는 엑셀(Excel®)이 자료를 디스크에 저장하는 정확한 방식을 알 필요가 없고 별 관심도 없다. 그러나 협력 개발업체 입장에서 XML 텍스트 구조는 역공학으로 분석하여 응용 프로그램에 접목하기가 한결 수월하다. 어휘 문서가 부실하고 일관성도 떨어지는 오픈오피스 XML조차도 예전 이진(binary) 형식에 비하면 수천 배는 편하다. 게다가 오픈독(OpenDoc)처럼 좀더 합리적이고 좀더 플랫폼에 무관하고 좀더 기존 기존 형식에서 자유롭다면 금상첨화라 하겠다.

2008 년 현재, 오피스 문서에서 사용하는 XML 어휘를 놓고 상당한 불평이 터져나오지만 어느 쪽이든 건설적인 논쟁은 거의 없다. 나는 마이크로소프트 사가 2월에 OOXML을 ISO 표준으로 통과시키려는 시도가 실패하리라 예상하지만 확신은 못하겠다. 어쨌거나 메시지는 분명하다. 앞으로 마이크로소프트 오피스는 오픈오피스, iWorks 등 기타 경쟁 제품에 계속 시장 점유율을 잃어갈 것이다.

오피스가 나쁜 제품이라서가 아니다(오피스는 나쁜 제품이 아니다). 오픈 소스가 아니라서도 아니다(오피스는 오픈 소스가 아니다). 더 이상 올라갈 데가 없기 때문이다. 더 이상 성장할 여지가 없기 때문이다. 이제는 어느 정도 깊이, 어느 정도 빨리 추락하느냐는 질문만 남았다. 현재 마이크로소프트 왕국이 당면한 위협은 네델란드와 노르웨이처럼 오픈독과 오픈소스 솔루션을 필수적으로 요구하는 정부가 점차 많아지리라는 사실이다. 심각도는 덜하지만 PC가 널리 퍼지면서 윈도우와 오피스 가격이 전체 PC 가격의 절반을 넘는다는 사실 또한 희소식은 아니다. 어떤 면에서 마이크로소프트 사는 이미 문제를 인식하고 교사와 학생 가족과 학교와 눈꼽만치라도 연관되는 모든 사람을 대상으로 저가 학생/교사용 오피스 에디션을 내놓았다. 그러나 동시에 오피스의 불법복제방지 기능을 강화하고 있으니 ‘왼손이 하는 일을 오른손이 모르게 하라’라는 교훈을 확실히 실천하는 중이라 하겠다. 그렇다고 불법복제가 줄어들 가망성은 없으나 사용자를 오픈 소스 대안으로 몰아갈 가능성은 충분하다.

이제 모든 오피스 문서가 XML 형식이므로 한 형식을 다른 형식으로 바꾸기가 놀랍도록 쉬워졌다. 2008년은 XML 계열 중에서도 업계 판도를 뒤집은 기술인 XSLT가 나온 10주년이다. 새로운 2.0 버전은 더욱 강력하다. 조만간 경쟁 제품끼리 문서 형식을 변환하기가 너무도 쉬워져 대다수 사람은 더 이상 문서 형식을 따지지 않을 것이다. 변환 과정에서 몇몇 스타일이나 매크로를 잃을지도 모르지만, 어차피 범용적으로 사용하지 않는 기능이니 상관이 없다. 제품 개발업체가 문서 형식을 독점하는 현상은 이제 소소한 문제가 되었다.

물론 가장 중요한 변환은 오픈독과 OOXML 사이에 일어나는 변환이 아니라 오픈독이나 OOXML에서 XHTML로 이루어지는 하향 변환(down-conversion)이다. 현재 오픈오피스와 마이크로소프트 오피스가 제공하는 HTML 변환 기능은 아주 형편없다. 다른 개발업체가 끼여들 틈새가 충분하다. 가장 중요하게 기업 사이트 개발자들이나 웹 마스터들이 자기네 사이트용으로 내놓는 사용자 정의 템플릿(custom template)에 주목한다. 이런 템플릿 덕택에 일반인들은 기존 방식으로 마이크로소프트 워드 문서를 작성한 후 CMS(Content Management System)로 직접 읽어들일 수 있다. 편집 도구와 검토 도구도 제작하기 쉽다. (사람은 GUI 인터페이스를 사용하지만) 컴퓨터가 마크업을 모두 생성하므로 문법 오류와 양식 오류가 사라지기 때문이다. 2008년 말까지 모든 웹은 아니지만 지금보다 많은 웹이 이러한 상태에 이르리라 생각한다.

또 한 XSLT와 XML 오피스 형식은 기존에 숨겨졌던 자료를 드러내는 역할도 한다. 지난 수십 년 동안 수많은 비즈니스 문서가 읽히지 않은 채 파일 시스템 속에 묻혀 있었다. 물론 더 이상 쓸모 없는 문서도 당연히 많겠지만, 중요한 정보가 담겼으나 찾아낼 방도가 없어 잊혀진 문서도 있다. 기업 개발자들은 이러한 기존 오피스 문서를 새로운 XML 기반 형식으로 자동 변환한 후 XSLT와 XQuery로 조회가 가능하게 만듦으로써 잊혀진 정보에 생명을 불어넣을 것이다.

워드나 오픈 오피스 라이터와 같은 기존 오피스 프로그램을 저작 도구로 사용한다면 서버에서는 이를 어떻게 처리할까? 문서 내용을 클라이언트에서 서버로 옮기는 방법은? 여기서 2007년에 나온 두 가지 중대한 1.0 배포 기술이 진가를 발휘한다. 바로 APP(Atom Publishing Protocol)와 XQuery다.




위로


APP(Atom Publishing Protocol)

흔 히 기술에 익숙치 못한 사람들에게 웹 저작 방법을 가르칠 때는 두 가지 난제에 직면한다. 하나는 의미론적 마크업(Semantic Markup)을 이해시키는 일이고, 또 하나는 FTP 사용법을 가르치는 일이다. (표준 파일 열기 대화 상자조차 사용할 줄 모르는 컴맹이 많다는 사실을 명심한다. 그들은 모든 문서를 “내 문서” 폴더나 바탕화면에 저장한다. 실수로 다른 곳에 넣으면 찾지 못한다. 프로그래머는 계층이라는 개념을 알지만 많은 사용자는 그 정도로 추상적인 사고를 하지 못한다.)

오픈오피스 와 마이크로소프트 워드처럼 XML을 지원하는 워드프로세서는 첫 번째 문제를 해결한다. APP는 두 번째 문제를 해결한다. APP는 사전에 협약하거나 개념적인 모델을 공유하지 않고도 독립적인 클라이언트와 서버가 서로 통신할 수 있도록 표준 프로토콜을 제공한다. 웹 검색에서 HTTP가 맡았던 역할을 웹 저작에서는 APP가 맡는 셈이다.

소프트웨어 개발업체는 각 서버에서 돌아가는 APP 서비스와 통신하는 저작 도구를 개발할 수 있다. 독자적인 편집기 형태도 가능하고 워드나 오픈오피스와 같이 기존 오피스 제품의 플러그인 형태도 가능하다. 문서를 업로드하는 방법은 지역 디스크에 파일을 저장하는 방법만큼이나 쉽다. 아니, 때로는 더 쉬울지도 모른다. 새 문서를 제작하려면 게시할 URL과 사용자 이름과 암호만 있으면 충분하다(위키 스타일 사이트라면 사용자 이름과 암호도 필요 없다). 문서를 편집할 때는 문서 URL만 있으면 된다.




위로


저장소

이제 2008년에 (워드나 오픈오피스로) XML 문서를 작성하는 방법과 서버로 저장하는 방법을 알았다. 그럼 마지막으로 이 멋진 XML 문서를 어디다 저장할까?

전 통적으로 두 가지 방법이 있다. 하나는 파일 시스템에 저장하는 방법이고, 다른 하나는 관계형 데이터베이스에 BLOB(Binary Large Object)로 구겨넣는 방법이다. 둘다 많이 쓰는 방법이지만 어느 쪽도 웹 문서에는 적합하지 않다.

파일 시스템은 간단하고, 안정적이며, 널리 알려진 기술이지만 검색 기능이 매우 부실하다. 같은 데이터를 여러 곳에다 중복하여 저장하며, 문서 내부 구조를 전혀 알지 못하며, 하위 문서(subdocument) 단위로 쪼개지도 못한다.

관계형 데이터베이스는 특정한 순서가 없고 중복이 적은 데이터 조각을 저장하기에 아주 적합하다. 그러나 XML은 어느 쪽에도 속하지 않는다. 관계형 테이블을 XML 문서로 변환하기는 쉽지만(각 행을 요소로 만들고 각 필드를 속성이나 자식 요소로 만들면 된다), XML 문서를 관계형 테이블로 변환하기는 쉽지 않다. 많은 XML 문서는 순서가 있으며, 공백이 많고, 요소 유형이 섞여 있으며, 반복적이면서도 고유한 요소를 가지고, 중첩 단계를 예측하기 어려운 등 관계형 테이블에 적합하지 못한 특징이 다분하다. 특히 HTML이나 XHTML 등과 같은 웹 페이지는 이러한 특성을 모두 지닌다. HTML 문서와 XML 문서를 관계형 데이터베이스에 저장해도 되지만(간혹 MySQL을 사용하는 경우도 있다) 결과는 깔끔하지도 빠르지도 못하다. 문서를 작은 단위로 낱낱이 쪼개면 자료를 검색하고 선택하고 순서를 변경할 수는 있다. 그러나 적당한 성능을 얻기 위해 소모하는 비용 탓에 배보다 배꼽이 더 커져버린다. 비교적 간단한 작업이라도 원래 SQL 용도와 무관한 탓에 SQL 쿼리는 반 페이지를 훌쩍 넘어버리고, 복잡한 쿼리를 개발하고 유지보수하는 작업 또한 악몽이 된다.

또 다른 방법으로 각 문서를 BLOB로 저장해도 된다. 간단하고 빠른 방법이지만 문서 일부를 선택하거나 다른 문서와 결합하는 기능은 모두 포기해야 한다. 현재 응용 프로그램 논리는 PHP나 루비 등과 같은 서버측 프레임워크에서 구현하는 추세다. 데이터베이스는 그저 파일 시스템보다 문서 분리가 나은 대안에 불과하다.

우리에게 필요한 데이터베이스는 일반 웹 문서가 지니는 계층 구조를 (잘라내지 않고) 포용하는 데이터베이스다. 그리고 처음으로 이런 데이터베이스가 시장에 나왔다. 가격대가 다양하고, 안정적이며, 곧바로 쓸 수 있다. 저가 제품으로는 eXist와 버클리 DBXML이 두각을 나타낸다. 마크 로직(Mark Logic)과 같은 고가 XML 데이터베이스는 초기 비용을 감당할 여력이 되는 대형 출판사를 끌어들이고 있다. IBM DB2® 9 pureXML™과 같은 제품은 XML 문서와 테이블형 문서를 혼합하려는 고객들에게 XQuery를 퍼트리리라 예상된다.

이 같은 초기 제품과 비교하여 새로 나오는 제품은 더욱 안정적이고, 더욱 확장성이 있고, 더욱 신뢰성이 높다. 가장 중요하게는 모두가 여러 해 동안 개발한 끝에 나온 표준 언어인 XQuery 1.0을 공유한다. 한 데이터베이스에서 다른 데이터베이스로 응용 프로그램을 이식할 가능성은 필요 이상으로 강조된 반면, 한 서버에서 다른 서버로 개발자의 기술을 이식할 가능성은 필요 이상으로 간과되어 왔다. 여섯 종류나 되는 다양한 쿼리 언어를 그것도 6개월마다 배우고픈 사람은 없다. 이제는 배울 필요도 없다.

XQuery에서 갱신(Update) 부분은 급속도로 진전을 보이고 있다. 2008년 내에는 끝나지 않겠지만 이미 구현해도 좋을 정도로 안정적이다. 새 안이 나올 때마다 코드를 조금씩 손봐야 하는 수고를 꺼리지 않는다면 말이다. 올해 안으로 상황은 나아질 전망이다.

마지막으로 2008년에는 javax.xml.xquery가 출시될 예정이다. 이는 자바 프로그램을 XQuery 엔진/데이터베이스와 연결하는 표준 API다. XQuery용 JDBC라 하겠다. 이 API를 사용하면 자바 코드와 XQuery를 섞어쓸 수 있다. 2009년 자바 7이 출시된 후에야 표준 자바 라이브러리 클래스에 들어가겠지만, 이미 많은 제품에서 이를 지원하며, 앞으로 그 수가 늘어날 전망이다.




위로


향후 방향

소셜 북마크
mar.gar.in
Digg this story
Post to del.icio.us
Slashdot it!

XQuery 는 드디어 실전에 투입될 준비를 갖추었다. APP는 막 출전하려는 참이다. 나더러 XML에 시간과 돈을 투자하라면 바로 이 두 가지 기술을 주목하겠다. CMS, 블로그 엔진, 게시판은 이미 넘치게 많다. 그러나 문서를 쉽게 저장하고 게시하는 방법은 부실하다. 전용 XML 데이터베이스와 APP가 이러한 요구를 충족시킨다.

그리고 이 자리를 빌어 개발자 도구를 하나 더 요청한다. 앞서 소프트웨어 개발에서 XML은 미래가 없다고 말했지만 그래도 아직 생명은 남아 있다. JSON이 가르치는 교훈을 살펴보면, 응용 프로그램은 그리 확장성 있는 자료 구조를 필요로 하지도 않고 원하지도 않는다. 기본 자료 유형과 리스트와 맵을 지원하는 기본 XML 형식이면 충분하다. Listing 1처럼 간단한 XML 말이다.


Listing 1. XML 기본 자료 형식

<PRE class=displaycode> <data xmlns="http://www.w3.org/data"> <list> <string>Foo</string> <int>17</int> <year>1999</year> <list> <map> <entry> <string>Boston</string><string>Red Sox</string> </entry> <entry> <string>New York</string><string>Yankees</string> </entry> </map></data></PRE>

위와 같은 XML 문서를 자바, 자바스크립트, 파이썬(Python), 펄(Perl), 루비(Ruly)와 같은 언어의 고유(native) 자료 구조로 변환하는 라이브러리는 어떨까? JSON과 비슷하지만 XML 확장성을 고려하면서도 보안 문제가 없는 도구가 가능할까? 도전해 볼 해커가 있는가?



 

참고자료

교육


제품 및 기술 얻기

  • eXist 전용(native) XML 데이터베이스: 전적으로 XML 기술에 기반을 둔 오픈 소스 데이터베이스 관리 시스템으로, XML 데이터 모델에 따라 XML 데이터를 저장하고 XQuery를 사용할 수 있다.

  • IBM 평가판 소프트웨어: IBM 평가판 소프트웨어를 developerWorks에서 바로 내려받을 수 있다.


토론



 

필자소개


Elliotte Harold: 교수, Polytechnic University

+ Recent posts