조금 유행이 지난이야기인듯 하지만,
MS의 OOXML을 ISO 표준으로 채용할지에 대한 논의도 탈도 많은듯 하다.
나는 정치적인 문제인듯 하고 ODF나 OOXML을 깊이 보지도 않아서 OOXML의 표준화 반대 서명에 참여하지도 않았다.

그런데 경험상 할 이야기는 있다.
난 ThinkFree Calc라는 Excel 호환 Spreadsheet을 만드는 팀에 있었는데
그 중 '머리말/꼬리말' 기능을 구현하던 시절이 있었다(치질없던 꽃미남 시절... 아. 벌써 그게 언제냐..)
xls 파일 형식을 분석하던 도중 재밌는 부분이 발견되었는데 text styling 정보에 대한 것이다.
half-brain이 아닌 이상 글자의 plain, underline, italic, bold 등의 정보는 0x00, 0x01,0x02,0x04 등의 상수로 bitmasking 놀이를 통해 하나의 숫자로 표현한다.

조금 더 낙천적인 사람은 'PLAIN','UNDERLINE' 등의 문자열 상수로 tagging을 하도록 설계할 수도 있다. 그래 그럴수 있다.

그런데 xls에서는 '굵게', '밑줄' 이런 문자열이 직접들어있어서 경악했었다. 정확한 형태는 기억안나지만 대충 이런 문자열이 들어있다.

전지현 보단 김태희

이런 효과를 내기위해

영어 locale에서는

[bold]전지현[/bold] 보단 [underline]김태희[/underline]

이라고 적혀있고 한글 locale에서 저장한 경우는

[굵게]전지현[/굵게] 보단 [밑줄]김태희[/밑줄]

이런식이다. 일본어, 베트남어가 추가된다면 각 언어별 keyword를 별도로 parsing해야 한다.

Microsoft는 바보집단이 아니다. 오히려 천재집단에 가까운데 이런 포맷을 유지하는 것은 이 포맷이 너무 많이 퍼져서 플랫폼이 되어 버렸기 때문이다.
바꾸고 싶은 마음은 굴뚝같아도(굴뚝같다는 표현의 어원은 무엇일까?) 국제화가 이슈되기 전에 너무 많이 플랫폼이 퍼져버렸다.

이는 API를 제정하는 것과 같다. java.io가 이미 널리 퍼졌는데 손재주로 더 개선이 어려우면 java.nio(New IO) 패키지를 만드는 수 밖에 없다. 첨단 기능을 쓰려는 사람에게 '공부'라는 짐을 주기는 하지만 하위호환성이 더 중요하기 때문이다.

MS의 OOXML은 새 API를 제공하겠다는 기회라고 생각된다. 이 기회에 구닥다리 문제점들을 정리하면 좋을텐데 그렇지 않은가 보다.
OOXML 뭐가 그리 대단한가?(한글)라는 글을 보니 기존 BIFF(Binary Interchangable File Format) 레코드를 tag 변환한 수준인듯 하다. 즉, 기계어를 어셈블러로 변환한 수준이란다.(오해를 살 수 있어서 밝히자면 난 OOXML 포맷을 제대로 읽은 적도 없고 XML 전문가도 아니다)
이 글에 방금 위에서 언급한 이슈도 나오는듯 하다. 이는 안타까운점이라고 생각한다.
그렇다면 이를 구현하기 쉬운 오피스는 이미 doc, xls, ppt를 이해하고 있는 오피스 벤더들이다.(예를들면 thinkfree? ^^)
뭐 그렇다 치자. 그동안 고생많이한 업체가 구현하기 쉬운건 당연하니까.

그런데 문제는 표준에 대한 것이다. 표준의 핵심은 목적을 이룰수 있어야 하며 최대한 간단해야 한다는 것이라 생각한다.
즉, 핵심이 아닌기능은 빠져야 한다는 것이다.
자바 API로 시스템 클립보드의 모든 flavor에 접근할 수는 없다. 하지만 Sun JVM의 비표준 클래스(com.sun으로 시작하는 패키지)를 이용하면 가능하다. 하지만 적어도 표준 API로만 만들어진 프로그램은 VM vendor에 상관없이 돌아간다. portability에 대한 이야기다. 어떤 문서 포맷이 더 강력한가에 대한 이야기가 아니다.
'시계'에 대한 표준을 만드려면 시,분,초를 얻어오는 메소드와 시간변화에 따른 refresh에 필요한 callback만 있으면 된다. digital/analog 표시 전환이나 계산기 기능은 표준에 들어갈 내용이 아니다.
즉, '문서 교환'이라는 '목적'을 이루기 위한 최소한의 명령셋을 정해야 하는 것이다.
그런데 '최소한의 명령셋'의 문제점은 feature loss가 생긴다는 점이다. 위의 시계작성 표준 API는 millisecond 정보를 유실케된다.
ODF는 OOXML에 비해 simple한데 따라서 OOXML->ODF 변환을 하면 유실되는 부분이 분명히 발생한다.
MS는 강력한 기능을 가진탓에 이런 loss가 없길 바랬나보다.
사실 millisecond를 유지하는 꼼수는 얼마든지 있을 것이다. 하지만 꼼수는 공유되지 않고 보통 그럴 가치도 없다.
확실한 방법은 'millisecond 정확도의 시계 표준'을 정의하는 것이다.
바꾸어 말하면 MS가 이루려는 목표를 fair하게 이루려면 'MS Office 호환 문서 표준' 이라고 이름을 바꾸어야 할 것이다.

써 놓고 보니 이런데 끼는거 싫다면서 입장을 너무 분명하게 밝힌듯 하다. 하지만 성명서에 나온 내용에 100% 공감하는건 아니어서 앞으로도 어느쪽에도 투표는 안 하려고한다. 그리고 이걸 논하는데 RELAX-NG나 non-mixed model 은 별 관련없는거 같고 '현학적인 표현으로 자신의 의견에 아우라를 펼치려는게 아닌가?' 하는 의심이...^^

P.S) 그런데 ISO 표준을 결정하는 한국 대표단이 누구누구 인가요? ^^