한빛출판네트워크

제공 : 한빛 네트워크
저자 : Rick Jelliffe
역자 : 남현우
원문 : Defining markup languages using Unicode properties

XML은 꽤 잘 정의된 규칙들을 가지고 있기 떄문에 우리는 XML 문서상의 정보를 방향성 그래프로 나타낼 수 있다. 즉, 속성(attribute)을 가지는 노드로 구성고 서로를 가리키는 트리형태의 자료구조로 나타낼 수 있다. (사실 문서간의 링크까지 포함한다면 모든 노드는 여러개의 루트 중 하나로부터 도달가능한 방향성 그래프라고 할 수도 있지만, 필자는 트리가 적합하다고 본다.)

XML의 선조격인 SGML에서는 구분자(delimiter)를 직접 정의할 수 있다. 그리고 임의의 문자를 정의하여 어떤 문맥 안에서 그것이 다른 태그나 데이터를 링크하도록 만들 수 있다(SHORTREF). 이러한 점 때문에 SGML은 위키와 비슷한 마크업이 가능하다. SGML의 또다른 기이한 특징 중 하나는 CONCUR라는 전문적인 툴에 의해서만 지원되는데, 엘리먼트에 임의의 접두어(prefix)를 붙일 수 있다. (네임스페이스 접두어와는 다르게 한번에 하나만 사용할 수 있다.) 이러한 특징은 병렬적인(concurrent) 마크업을 가능하게 한다. 예를들어 한 태그집합은 문단을 표현하고 다른 태그집합은 행을 표현하되 이들이 서로 혼용되지 않는 선에서 사용하는 것이 가능하다.

최근 몇 년 간, W3C XML 그룹은 유니코드에 대한 변경사항을 XML에 적용하려고 노력하고 있다. XML 1.1과 XML 1.0 (fifth edition)은 Elliotte Rusty Harold나 James Clark같은 사람들을 매우 화나게 만들었는데, 문제는 유니코드에 없는 문자를 등록하고 엘리먼트의 이름으로 사용하지 못한다는 점이었다. [추가:Tim Bray, David Carlisle] XML 그룹은 이에 책임이 있다. XML 1.1은 이에 대해 사용하지 못하던 유니코드가 아닌 문자들을 명시하고 이들을 사용할 수 있는 방법을 택했다. XML (fifth edition)도 마찬가지의 방법을 택했다. 필자로서는 여지껏 큰 문제 없이 써오던 방법을 왜 대중적이지 않은 방법으로 대체했는지 의문이지만 이것은 지금 중요하지 않다.

엘리먼트나 속성의 이름으로 사용될 문자를 선택하는 제 3의 방법도 있다. 이는 유니코드의 속성(properties)를 사용하는 것이다. 유니코드는 각 문자마다 많은 속성을 정의하고 있다. 예를 들어, 문자가 알파벳인지, 숫자인지, 기호인지를 속성으로 나타낸다. 만약 어떤 문서가 파서가 지원하는 유니코드 버전보다 최신의 버전을 사용한다면 어떻게 될까? 사실, 파서는 OS보다 빨리 업데이트되거나 OS의 기능 중 일부이기 때문에 만약 어떤 문서를 OS가 인식하지 못한다면 파서도 그럴것이고 파싱의 의미가 없어진다. 이는 최신 기술을 사용할 때 흔히 겪는 일이다.

위 문제제기는 흥미로운 대안을 떠올리게 한다. 우리가 유니코드 속성을 사용하는, XML형태를 받아들이고 SAX형태의 이벤트 스트림을 생성하는 마크업 언어를 정의할 수 있을까?

문서에 세 종류의 텍스트가 있다고 하자.

     text = data + 토큰태그(token-tags) + 복합태그(complex-tags). 

토큰태그는 다음과 같이 정의되는 시퀀스이다.

1. (짝없는) 기호로 시작한다.
2. 잇따라 임의의 개수의 (짝없는) 기호 혹은 구둣점(punctuation)이 나온다.
3. 잇따라 임의의 개수의 (글자/표의문자/숫자/세미콜론을 제외한 구둣점)로 구성된 토큰이 나온다.
4. 세미콜론을 포함한 (짝없는) 기호나 공백 혹은 다른 문자로 끝난다.

위 규칙에 대한 예로 {를 들 수 있는데, 이것으로 토큰태그는 XML 엔티티 레퍼런스 규칙을 포함한다는 것을 알 수 있다. 물론 @xxx와 같은 것도 가능하다.

위에서 짝없는 기호란 다음 유니코드 속성을 가지지 않는 문자를 뜻한다: PUNCTUATION OPEN, PUNCTUATION CLOSED, PUNCTUATION INITIAL QUOTE, PUNCTUATION FINAL QUOTE 혹은 (아마도) BIDI-MIRRORED.

짝이 있는 기호들은 복합태그의 구분자로 사용된다.

복합태그의 규칙은 다음과 같다.

1. PUNCTUATION OPEN (혹은 BIDI-MIRRORED)로 시작한다.
2. 짝없는 기호가 임의의 개수만큼 나올 수 있다.
3. 토큰, 공백, 짝없는 구분자, 토큰태그 혹은 복합태그가 나온다.
4. 1번과 대응하는 PUNCTUATION CLOSE 문자로 끝나며, 그 뒤에 짝없는 기호가 임의의 개수만큼 나올 수 있다.

다음이 복합태그의 예이다.

다음도 가능하다.

   struct X { integer: X; integer y} 
   (eval(unquote(car "X))) 
   <$page$>dark and stormy night 

파서가 처음 진행하는 작업은 문서에서 가능한 모든 토큰태그와 복합태그를 찾는 것을 포함한다. 이 태그들은 들은 겹쳐진 형태로 존재할 수도 있다. 이렇게 찾아진 토큰은 SAX에서처럼 이벤트 스트림의 이벤트로 간주된다. 애플리케이션은 각 이벤트를 처리하거나 그냥 건너뛴다. 이벤트를 건너 뛸 경우 해당 토큰의 첫 구분자는 문자데이터로 재해석하고 그 뒤의 문자도 이에 맞게 재해석된다. (이 방법은 Cameron교수가 Simon Fraser 대학에서 연구한 lookahead pipelined block parsing에 적합하다. 링크 참조)

물론 이 방식은 XML이 제공하는 것 보다 훨씬 저수준의 토큰화를 제공한다. 그러나 중첩 태그를 허용하는 XML을 포함한 다른 많은 언어들이 이 방식에 기반하고 있다. 이와같이 언어가 재구성될 수 있으며, 재구성된 언어(토크나이저)들은 합쳐져서 사용되는 것이 SGML의 특징이다. (예: XML + CSS + javascript) 물론 이 방식을 제한된 형태로 사용해서 토큰태그의 시작 기호로 &만 허용하고, 외부 복합태크의 시작 구분자로 <만을 허용하며, <로 시작한 복합태크 안에서는 시작 구분자로 "와 ""만 허용하도록 할 수 있다. 결국 이는 XML을 확장한 형태의 문법과 비슷하며, 다음을 보면 알 수 있다.

 
 
 
 
<$ some new kind of tag $> 
<% some other kind of tag %> 

필자는 위 방식이 바람직하다고 생각한다. 많은 사람들이 XML이 너무 많은 마크업을 가진다고 말하지만 필자는 턱없이 부족하다고 생각하며 특히 데이터형식을 나타내는 마크업이 부족하다고 생각한다. 심지어 어떤것이 숫자인지 문자열인지도 표현할 수 없다. <과 심볼 사이에 공백을 넣는 것은 현재로서는 가능하지만 앞으로는 그렇게 사용되지 말아야 한다.

물론 이러한 기능들이 가능하기는 하지만, 이를 굳이 사용할 필요는 없다.