 |
|
난이도 : 초급 Michael Kay, 필자 겸 프로그래머, Saxonica Limited
옮긴이: 박재호 이해영 dwkorea@kr.ibm.com
2008 년 10 월 21 일 XSLT는 어떤 언어일까? 무슨 목적으로 사용할까? 왜 이렇게 만들었을까? XSLT를 보는 관점에 따라 답은 여러 가지입니다. XSLT는 여느 프로그래밍 언어와 많이 달라서 초보자들이 혼란을 많이 겪습니다. 이 기사에서는 실생활 예제를 이용하여 XSLT를 살펴봅니다. XSLT 스타일시트 작성법을 지루하게 설명하는 대신, XSLT라는 언어가 나온 배경, 언어가 제공하는 장점, 언어를 사용해야 하는 이유 등을 소개합니다.
원래 나는 Saxon 관련 기사를 쓰면서 기술적인 배경을 설명할 목적으로 이 기사를 작성했다. 처음 의도한 기사는 전형적인 XSLT 프로세서에서 사용되는 구현 기술을 소개하려는, 그래서 사용자가 스타일시트를 좀 더 효율적으로 사용하도록 도우려는 기사였다. 하지만 developerWorks 편집진은 많은 독자들이 관심을 보이리라며 Saxon 기사 도입부를 XSLT 언어 설명을 제공하는 별도 기사로 올리자고 제안했다.
XSLT란?
XSLT라는 언어는 W3C(World Wide Web Consortium)에서 정의했으며, XSLT 버전 1.0은 1999년 11월 16일에 권고안(Recommendation)으로 발표되었다(자세한 내용은 참고자료를 살핀다). 내 저서 XSLT Programmer’s Reference에서 언어 명세를 상세히 설명하므로 여기서 같은 내용을 반복하지는 않겠다. 이 기사에서는 전체적인 그림을 보면서 XSLT의 역할을 이해하는 방향에 초점을 맞춘다.
XSLT의 역할
XSLT는 정보를 표현(presentation)과 내용(content)으로 분리하려는 의도에서 나왔다. HTML은 문단(paragraph), 강조(emphasis), 순서가 있는 목록(numbered list) 등의 추상 용어로 표현을 정의하여 표현과 내용을 어느 정도 분리했다. 그런데 웹이 점차 상업성을 띄면서 출판업계에서는 인쇄물과 비슷한 수준으로 출력 결과를 제어하고 싶어했다. 그래서 점차 글꼴을 명시적으로 지정하거나 페이지에서 위치를 절대적으로 지정하는 경우가 많아졌다. 그러다 보니, 안타깝지만 당연하게도, 같은 내용을 디지털 TV나 WAP 단말기 등과 같은 장치에 표시하기가 점차 어려워졌다(출판업계에서는 용도 변경(repurposing)이라는 표현을 쓴다).
인쇄물 출판업계에서 사용하던 마크업 언어인 SGML을 토대로 1998년 일찌감치 정의된 XML은 내용과 표현을 분리했다. (문단, 목록, 표 등) 태그 수가 고정된 HTML과는 달리, XML에서 사용하는 태그는 모두 사용자가 정의하므로 (사람, 장소, 가격, 날짜 등) 분야마다 자신들이 필요한 객체를 직접 정의해 사용할 수 있다. (추상화는 했지만) 본질적으로 인쇄용인 HTML 엘리먼트와는 달리, XML 엘리먼트는 실생활 객체를 묘사한다. 예를 들어, Listing 1은 축구 토너먼트 결과를 표현하는 XML 문서다.
Listing 1. 축구 토너먼트 결과를 표현하는 XML 문서
<results group="A">
<match>
<date>10-Jun-1998</date>
<team score="2">Brazil</team>
<team score="1">Scotland</team>
</match>
<match>
<date>10-Jun-1998</date>
<team score="2">Morocco</team>
<team score="2">Norway</team>
</match>
<match>
<date>16-Jun-1998</date>
<team score="1">Scotland</team>
<team score="1">Norway</team>
</match>
<match>
<date>16-Jun-1998</date>
<team score="3">Brazil</team>
<team score="0">Morocco</team>
</match>
<match>
<date>23-Jun-1998</date>
<team score="1">Brazil</team>
<team score="2">Norway</team>
</match>
<match>
<date>23-Jun-1998</date>
<team score="0">Scotland</team>
<team score="3">Morocco</team>
</match>
</results>
|
웹 브라우저에서 축구 결과가 담긴 위 XML 파일을 연다면 브라우저가 페이지를 올바로 표시하리라 기대하기 어렵다. 브라우저든, TV 화면이든, WAP 단말기든, 지면이든 내용을 올바로 표시하는 방법을 알려줄 메커니즘이 필요하다. 여기서 스타일시트라는 개념이 나왔다. 스타일시트는 XML 문서에서 태그로 둘러싼 정보를 어떻게 표시할지 정의하는 선언적인 규칙 집합이다.
W3C는 스타일시트 표준으로 두 종류를 정의했다. 하나는 CSS(Cascading Style Sheet)로, HTML에서 널리 사용하는 표준이다. 참고로, CSS를 XML에서 사용해도 괜찮다. CSS를 사용하는 예를 하나 들자면, 송장에서 총 금액을 표시할 때 16pt Helvetia Bold 글꼴을 사용하라고 지정할 수 있다. 그러나 CSS는 계산을 수행하지 못하며, 자료를 재배열하거나 정렬하지 못하며, 여러 곳에서 자료를 가져와 병합하지 못하며, 사용자나 세션에 따라 스타일 특성을 변경하지 못한다. 그래서 우리의 축구 예제는 CSS로 부족하다(심지어 최신 버전인 CSS2로도 부족하다. 게다가 아직 CSS2를 지원하지 못하는 제품이 많다). 이런 이유 때문에 W3C는 기능이 좀 더 풍부한 스타일시트인 XSL(Extensible Stylesheet Language)을 개발하기 시작했다. XSL은 SGML 공동체가 개발한 DSSSL(Document Style, Semantics, and Specification Language)에서 지적인 아이디어를 많이 가져왔다.
XSL을 개발하는 과정에서 (DSSSL에서 이미 예견되었듯이) XML 문서를 준비하는 과정이 두 단계로 나뉜다는 사실이 분명해졌다. 하나는 변환(transformation)이고, 다른 하나는 형식화(formatting)였다. 변환은 한 XML 문서를 (혹은 메모리에 있는 XML 표현을) 다른 문서로 바꾸는 작업이다. 형식화는 변환된 트리 구조를 2차원 그래픽 표현으로 혹은 1차원 오디오 스트림으로 바꾸는 작업이다. XSLT는 첫 번째 단계인 변환을 제어하는 언어로 개발되었다. 두 번째 단계인 형식화를 제어하는 언어는 여전히 개발 중이다. 하지만 현재 많은 사람이 XSLT로 XML 문서를 HTML 문서로 변환한 후 형식화 엔진으로 HTML 브라우저를 사용한다. 사실상 HTML은 XML 어휘 중 하나이며 XSLT가 XML 어휘를 사용해 목표 언어로 쉽게 변환하기 때문이다.
변환 언어와 형식화 언어를 분리하겠다는 결정은 아주 올바른 결정으로 드러났다. 알고 보니, XML 문서를 사용자에게 보여주려는 목적 외에도, 변환 언어를 사용할 응용 분야가 아주 많았다. XML이 정보 교환 형식으로 전자 상거래 분야에서 인기를 끌면서 한 XML 어휘를 다른 XML 어휘로 변환할 필요성도 점차 커져갔다. 예를 들면, 전자 프로그램 안내서(EPG)에서 TV 프로그램 정보를 추출한 후 다운로드 당 요금을 지불하는 고객에게 보낼 고지서에 넣으려는 경우가 좋은 예다. 또한 원본 어휘와 대상 어휘가 똑같은 상황에도 정보를 변환할 필요가 생긴다. 예를 들면, 자료를 필터링하거나 가격 인상분을 적용하는 경우가 여기에 해당한다. 이렇듯 XML 형식으로 작성된 정보가 증가하면서 XSLT는 점차 XML을 조작하는 궁극적인 고차원 언어로 널리 사용되기 시작했다.
내 책에서 나는 XSLT와 XML 사이에 존재하는 관계가 SQL과 표 형식을 따르는 자료(tabular data) 사이에 존재하는 관계와 같다고 주장했다. 관계형 모델이 널리 퍼진 이유는 자료를 표 형식으로 정렬하겠다는 아이디어 때문이 아니었다. SQL을 사용하여 관계 해석(Relational Calculus)에 기반을 두고 고차원적으로 자료를 조작하는 능력 때문이었다. 마찬가지로 XML이 주목 받는 이유는 계층적인 자료 모델 때문이 아니다. 계층적인 자료 모델 자체는 응용 프로그램 개발자에게 별다른 도움을 주지 못한다. XML이 주목 받는 이유는 XML 자료를 고차원적으로 조작하는 언어인 XSLT가 존재하기 때문이다.
언어로서 XSLT
언어로서 XSLT는 다소 흥미로운 작품이다. 이 기사에서 언어 설계와 관련한 결정이나 배경은 언급하지 않는다. 구체적인 내용은 언어 설계자들이 명시한 요구사항을 추적하다 보면 충분히 이해하리라 생각한다. 좀 더 자세히 이해하고 싶다면 내 책 1장을 읽어본다.
언어로서 XSLT가 제공하는 핵심 기능 몇 가지를 열거한다.
XSLT 스타일시트 자체가 XML 문서다. 문서 구조는 꺽쇠 괄호(<>) 태그를 사용하는 XML 문법을 따른다. 그래서 문법이 다소 어설프며 언어가 다소 장황하다. 하지만 장점도 있다. (유니코드 문자 인코딩과 이스케이프 메커니즘, 외부 엔티티 사용 등) XML의 어휘적인 요소를 모두 자동으로 사용할 수 있다. XML 스타일시트를 변환 입력이나 변환 결과로 만들기 쉽다(즉, 언어에서 제공하는 재귀적인 특성을 이용한다). 또한 스타일시트 내부에 원하는 XML 결과를 추가하기도 쉽다. 실제로도 간단한 스타일시트를 작성하여 출력 문서 템플릿으로 사용하는 경우가 많다. 템플릿 내에 값을 삽입하거나 계산하는 XSLT 명령을 내장하면 충분하다. 이렇듯 단순한 수준에서 XSLT는 현재 기업이 판매하는 독점 HTML 템플릿 언어와 매우 비슷하다.
기본적인 처리 방식이 패턴 일치다. 기본적인 처리 방식 측면에서 펄 등 여러 텍스트 처리 언어와 마찬가지로, XSLT는 1960년대 스노볼이라는 언어의 전통을 따른다. XSLT 스타일시트는 템플릿 규칙 집합으로 이루어지며, 각 템플릿 규칙은 "입력이 이 조건을 만족하면 다음 결과를 출력하라"라는 형태다. 하지만 여기서 규칙 순서는 중요하지 않다. 입력에 일치하는 규칙이 여럿일 때 충돌을 해결하는 알고리즘이 따로 있다. 그러나 XSLT가 다른 텍스트 처리 언어와 다른 점이라면 입력을 한 행씩 순서대로 처리하지 않는다는 사실이다. XSLT는 입력 XML 문서를 트리 구조로 취급하여 각 템플릿 규칙을 트리 노드에 적용한다. 다음으로 처리할 노드는 템플릿 규칙에서 결정하므로, 노드를 처리하는 순서가 문서 순서와 반드시 일치하지는 않는다.
XSLT 프로세서 동작 방식
XSLT 프로세서는 트리 구조를 입력으로 받아 또 다른 트리 구조를 출력한다. 이 과정을 표현하면 그림 1과 같다.
그림 1. XSLT 프로세서가 동작하는 방식
입력 트리 구조는 흔히 XML 문서를 분석한 결과다. 출력 트리 구조는 흔히 다른 XML 문서로 직렬화된다. 하지만 XSLT 프로세서 자체는 트리 구조를 조작할 뿐 XML 문자 스트림은 관여하지 않는다. (처음에는 비록 많은 사용자들이 실용적이지 못하다고 여겼으나) 이 개념은 아주 복잡한 변환을 수행하는 데 결정적인 열쇠로 드러났다. 첫째, 원본 문서에서 트리 구조와 관계 없는 부분은 XSLT 프로세서가 접근하지 못한다. 다시 말해, 속성에 단일 인용부호를 사용하느냐 혹은 이중 인용부호를 사용하느냐에 따라 원본 문서를 다르게 처리하지 못한다는 뜻이다. 어디까지나 문서 표현이 다를 뿐 문서 구조는 동일하기 때문이다. 둘째로, 입력 엘리먼트를 처리하는 연산이나 출력 엘리먼트를 생성하는 연산은 원자적인 연산이다. 다시 말하면 트리 모델에서 엘리먼트는 원자적인 노드 하나로 표현하므로 엘리먼트 내에서 시작 태그를 처리하는 부분과 끝 태그를 처리하는 부분을 분리하지 못한다는 뜻이다.
XSLT는 XPath라는 하위 언어를 사용하여 입력 트리의 노드를 참조한다. XPath는 기본적으로 XML 계층 모델에 일치하는 조회 언어다. 트리 내에서 자유자재로 이동하면서 노드를 선택할 수 있으며, 노드 값과 위치에 따라 술어(prediate)를 적용할 수 있다. 또한 XPath는 기본적인 문자열 조작, 수학 계산, 부울 연산도 제공한다. 예를 들어, XPath 표현식 ../@title은 현재 노드의 부모 엘리먼트에서 title 속성을 선택한다. XPath 표현식은 처리할 입력 노드를 선택하고, 조건부 처리에서 조건을 확인하고, 결과 트리에 삽입할 값을 계산하는 용도로 쓰인다. XPath 표현식을 단순화한 형태인 패턴(pattern)은 템플릿 규칙을 적용할 노드를 정의할 때도 쓰인다. W3C는 XPath를 별도 권고안으로 정의하는데, 확장 하이퍼링크를 정의하는 XPointer처럼 XPath를 다른 용도로도 사용하기 위해서다.
XSLT는 리스프(Lisp), 해스켈(Haskell), 스킴(Scheme) 등과 같이 함수 프로그래밍 개념에 기반을 둔다. 스타일시트는 템플릿으로 이루어지며, 각 템플릿은 본질적으로 순수 함수다. 각 템플릿은 입력 트리 일부를 받아 출력 트리 일부를 생성하며, 부수적인 효과(side-effect)는 없다. 부수적인 효과가 없다는 규칙은 매우 엄격히 적용된다(자바 같은 언어로 작성된 외부 코드로 잠시 빠져나가서 수행하는 경우는 예외다). XSLT 언어는 변수를 정의할 수 있지만, 기존 변수 값을 바꾸지는 못한다. 언어에 할당문이 없기 때문이다. 언어를 처음 접하는 사용자는 흔히 어리둥절해하지만, 이러한 정책을 세운 이유는 스타일시트를 점진적으로 적용하기 위해서다. 언어에 부수적인 효과가 전혀 없다면, 입력 문서를 조금 변경했을 때, 문서 전체를 다시 변환하지 않고도 결과에서 변할 부분만 계산할 수 있다는 이론이다. 현재는 어디까지나 이론에 불과하다. 아직까지 이 이론을 실현한 XSLT 프로세서는 없다. (참고: XSLT는 함수 프로그래밍 개념에 기반하지만, 그렇다고 전적으로 함수 프로그래밍 언어는 아니다. 함수를 언어 자체에서 제공하는 자료 유형으로 취급하지 못하기 때문이다.)
스타일시트 예제
지금쯤에서 예제를 살펴보면 언어를 명확하게 이해하기가 쉬워지리라 생각한다. Listing 2는 축구 경기 결과를 열거하는 간단한 스타일시트다.
Listing 2. 축구 경기 결과를 열거하는 간단한 스타일시트
<xsl:transform
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="results">
<html>
<head><title>
Results of Group <xsl:value-of select="@group"/>
</title></head>
<body><h1>
Results of Group <xsl:value-of select="@group"/>
</h1>
<xsl:apply-templates/>
</body></html>
</xsl:template>
<xsl:template match="match">
<h2>
<xsl:value-of select="team[1]"/> versus <xsl:value-of select="team[2]"/>
</h2>
<p>Played on <xsl:value-of select="date"/></p>
<p>Result:
<xsl:value-of select="team[1] "/>
<xsl:value-of select="team[1]/@score"/>,
<xsl:value-of select="team[2] "/>
<xsl:value-of select="team[2]/@score"/>
</p>
</xsl:template>
</xsl:transform>
|
이 스타일시트는 템플릿 규칙 두 개로 이루어진다. 하나는 <results> 엘리먼트를 처리하는 규칙이고, 다른 하나는 <match> 엘리먼트(이름에 혼동이 오더라도 용서하길)를 처리하는 규칙이다. <results> 엘리먼트를 처리하는 규칙은 HTML 헤더 정보와 제목(<h1>)을 출력한 후 <xsl:apply-templates/>를 호출한다. 이는 현재 노드에서 모든 자식 노드에 적절한 템플릿 규칙을 적용하라는 명령이다. 우리 예제에서 <results> 엘리먼트 자식은 모두 <match> 엘리먼트다. 따라서 두 번째 템플릿 규칙이 각 <match> 엘리먼트에 적용된다. 두 번째 템플릿 규칙은 경기 이름(<h2>)을 "브라질 대 스코틀랜드"처럼 출력한 후 경기 날짜와 양팀 득점(<p>)을 출력한다.
변환을 수행하고 나면 HTML 문서가 얻어진다. 그림 2는 이 HTML 문서를 브라우저에 표시한 결과다.
그림 2. Listing 2 스타일시트를 적용한 결과
그림 2는 정보를 매우 직설적으로 표현한다. 하지만 XSLT는 훨씬 더 강력하다. Listing 3은 같은 정보를 다른 방식으로 변환하는 스타일시트다. 이 스타일시트는 토너먼트를 마친 후 팀 성적을 총괄적으로 계산하여 표를 생성한다.
Listing 3. 최종 팀 성적을 계산하는 스타일시트
<xsl:transform
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:variable name="teams" select="//team[not(.=preceding::team)]"/>
<xsl:variable name="matches" select="//match"/>
<xsl:template match="results">
<html><body>
<h1>Results of Group <xsl:value-of select="@group"/></h1>
<table cellpadding="5">
<tr>
<td>Team</td>
<td>Played</td>
<td>Won</td>
<td>Drawn</td>
<td>Lost</td>
<td>For</td>
<td>Against</td>
</tr>
<xsl:for-each select="$teams">
<xsl:variable name="this" select="."/>
<xsl:variable name="played" select="count($matches[team=$this])"/>
<xsl:variable name="won"
select="count($matches[team[.=$this]/@score > team[.!=$this]/@score])"/>
<xsl:variable name="lost"
select="count($matches[team[.=$this]/@score < team[.!=$this]/@score])"/>
<xsl:variable name="drawn"
select="count($matches[team[.=$this]/@score = team[.!=$this]/@score])"/>
<xsl:variable name="for"
select="sum($matches/team[.=current()]/@score)"/>
<xsl:variable name="against"
select="sum($matches[team=current()]/team/@score) - $for"/>
<tr>
<td><xsl:value-of select="."/></td>
<td><xsl:value-of select="$played"/></td>
<td><xsl:value-of select="$won"/></td>
<td><xsl:value-of select="$drawn"/></td>
<td><xsl:value-of select="$lost"/></td>
<td><xsl:value-of select="$for"/></td>
<td><xsl:value-of select="$against"/></td>
</tr>
</xsl:for-each>
</table>
</body></html>
</xsl:template>
</xsl:transform>
|
스타일시트를 일일이 설명하기는 지면이 부족하므로 생략한다. 전체적으로 요약하자면, 스타일시트는 teams라는 변수를 정의하는데, teams는 토너먼트에 참여하는 모든 팀의 인스턴스를 하나씩 포함하는 노드 집합이다. 변수를 정의한 후에는 각 팀이 다른 팀과 경기해서 이긴 횟수, 동점인 횟수, 진 횟수와 상대편에게 획득한 전체 득점 수를 계산한다. 그림 3은 Listing 3으로 얻은 결과를 브라우저에 표시한 모습이다.
그림 3. Listing 3 스타일시트로 얻은 결과
이 예제는 XSLT가 단순히 원본 글꼴이나 배치를 바꾸는 기능을 넘어 훨씬 더 복잡한 기능을 제공한다는 사실을 보여준다. XSLT는 (단순히 표현을 목적으로 원본 자료 모양새를 바꾸려는 목적만이 아니라) 다른 응용 프로그램에 제공하는 입력을 생성할 목적으로도 사용이 가능한 완전한 프로그래밍 언어다.
XSLT의 이익
XSLT를 왜 사용할까?
XSLT는 XML 문서 변환이라는 특수한 목적을 수행하는 언어로, 고차원 선언형 프로그래밍 언어가 제공하는 전통적인 장점을 모두 제공한다.
일반적으로 고차원 언어를 사용하는 이유는 개발 생산성이 높아지기 때문이다. 하지만 고차원 언어가 주는 실제 이익은 변경 가능성(potential for change)에 있다. 고차원 언어인 XSLT로 XML 자료 구조를 변환하는 응용 프로그램은 저차원 DOM과 SAX 인터페이스를 사용하는 절차적 응용 프로그램보다 XML 문서 변화를 훨씬 쉽게 수용한다. 데이터베이스 업계에서는 이러한 특성을 자료 독립성(data independence)이라고 부르는데, 이전 탐색형 자료 접근 언어가 쇠하고 SQL과 같은 선언형 언어가 성공한 이유가 바로 여기에 있다. 나는 XML 세상에서도 같은 현상이 벌어지리라 굳게 믿는다.
여느 선언형 언어와 마찬가지로, XSLT도 성능 문제라는 대가를 치른다. 하지만 대다수 응용 프로그램은 현재 XSLT 프로세서가 제공하는 성능으로 충분하다. 게다가 XSLT 프로세서의 성능은 점점 나아지는 추세다. 두 번째 기사에서는 내 Saxon 제품과 같은 XSLT 프로세서에서 사용하는 최적화 기술을 소개한다.
요약
이 기사에서는, SQL이 관계형 데이터베이스를 조작하는 고차원 언어이듯이, XSLT가 XML 문서를 조작하는 완전한 고차원 언어라는 사실을 살펴보았다. XSLT는 단순한 스타일 언어가 아니며 CSS보다 (심지어 CSS2보다) 훨씬 강력하다는 사실에 주목한다.
나는 모든 비즈니스 로직을 XSLT로 구현한 응용 프로그램을 이미 접해보았다. 어느 3계층 온라인 뱅킹 시스템에서 나는 다음과 같은 구조를 보았다.
- 시스템 뒷단에서는 모든 정보를 XML 메시지 형태로 가져온다.
- 온라인 세션 도중 사용자 계정 정보는 메모리에 XML DOM 형태로 표현한다.
- 사용자에게 보내는 모든 정보는 먼저 XML 메시지로 가져온 후, 서버나 클라이언트에서 XSLT를 사용하여 XML을 HTML로 변환한다. 변환이 일어나는 위치는 브라우저 능력에 따라 달라진다.
이 응용 프로그램은 모든 정보를 XML 형태로 가져오고 전송했으며, (자료 접근 로직, 비즈니스 로직, 표현 로직 등) 모든 로직을 XSLT로 구현했다. 이런 아키텍처를 모든 프로젝트에 권하기는 아직 무리이지만, 여러 모로 장점이 많은 프로그램이다. 앞으로 이런 시스템이 점차 많아지리라 생각한다.
프로그래밍 언어로서 XSLT는, XML 문법을 사용한다는 사실에서 함수 프로그래밍 언어에 기반을 둔다는 사실까지, 일반 웹 프로그래머에게 익숙하지 않은 특징이 많다. 즉, 언어를 익히기가 수월하지 않다는 뜻이다. 초창기 SQL도 배우기 어려웠으며, 그만큼 잠시 인기를 끌었다가 사라진 기존 개념과 크게 다르다는 뜻이다. 포기하지 말기 바란다. XSLT는 아주아주 강력한 기술이다. 시간과 노력을 들여 배워둘 가치가 충분하다.
후기
Michael Kay가 2005년 4월에 덧붙이는 말: 비록 4년 전에 쓴 기사지만, 현재까지도 내용은 유효하다. XSLT 2.0이 나오면서 언어는 크게 변했지만, 기사를 다시 읽어도 크게 고칠 내용은 없었다. XSLT 2.0은 새로운 기능을 많이 내놓았지만, 언어의 기본적인 개념은 앞서 설명한 바와 똑같다.
참고자료
필자소개 | 
| | Michael Kay는 ICL을 떠난 직후 이 기사를 썼다. ICL은 그가 24년 동안 몸 담으면서 객체지향, 관계형, 자유 문서 데이터베이스 소프트웨어인 Codasyl을 설계했던 회사였다. ICL을 떠난 후 그는 3년 동안 Software AG에서 XSLT 2.0 명세 편집자로서 일하며 W3C 표준을 정립하느라 애썼다. 현재 Michael Kay는 자신이 설립한 회사인 Saxonica를 운영하며 Saxon 관련 제품을 개발하고 서비스를 제공한다. 또한 Wrox를 통해 XSLT 2.0 Programmer's Reference와 XPath 2.0 Programmer's Reference 개정판도 펴냈다. 이 사진은 그가, Wrox 표지 사진과는 달리, 항상 심각한 사람이 아니라는 사실을 보여주고자 선택했다. |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| 
